releng/abcl-1.1.0/meetings/20120805: abcl-1.1.0-scrum-20120805.log

File abcl-1.1.0-scrum-20120805.log, 12.6 KB (added by Mark Evenson, 8 years ago)

Log of #abcl on 20120805

Line 
1[Mon Aug  6 2012]
2*** You have joined channel #abcl                                       [19:10]
3*** Topic for #abcl: abcl-1.1.0 All day, all week.
4*** #abcl: topic set by easye!~user@213.33.70.157, 02:40:47 2012/07/28
5*** Users on #abcl: easye loke fsmunoz specbot minion guaqua` dmiles_afk luis
6    flip214 hypno @V-ille Guest63158
7*** ChanServ (ChanServ@services.) has changed mode for #abcl to +o easye
8*** #abcl modes: +cnt
9*** #abcl was created on Tuesday 2009/01/27 06:29:31 AM
10* easye preps for the abcl-1.1.0 status at 2100 CET.                    [19:11]
11* fsmunoz lurks around just to see grown people talk about serious stuff
12                                                                        [19:24]
13<easye> Well, Erik is travelling, so I may be the only one around.      [19:26]
14* fsmunoz lurks around for easye's solo performance :)                  [19:28]
15<fsmunoz> still have some email re. the java interop I want to send, some
16          great answers there.                                          [19:29]
17<easye> Yes.  I thought there is quite a bit of material to expand on.  [19:30]
18<fsmunoz> most certainly. The "BTW, here is a doto macro in jss" was a
19          particularly good show :) All the answers had great information. The
20          only thing I'm slightly concerned about is the whole subclassing
21          thing.                                                        [19:31]
22<easye> I have learned so much by studying Alan's code. 
23<fsmunoz> I'm starting to, starting low but hey, it's very interestiung
24          nonetheless                                                   [19:33]
25<easye> The thing about Alan's code which rewards careful study is his use of
26        macros: usually a very precise application of pg's _On Lisp_ style
27        thinking.                                                       [19:34]
28<fsmunoz> Will keep an eye out for that                                 [19:42]
29<fsmunoz> Macro's still sometimes elude me in some ways
30<easye> Same here.  But with study...                                   [19:43]
31<fsmunoz> yeah                                                          [19:50]
32*** You have been marked as being away                                  [20:17]
33*** You are no longer marked as being away                              [20:52]
34*** rudi (~rudi@cm-84.208.89.228.getinternet.no) has joined channel #abcl
35                                                                        [20:54]
36*** ChanServ (ChanServ@services.) has changed mode for #abcl to +o rudi
37* easye waves to rudi.
38<rudi> hi - back with severe sleep deficit, but more or less back in action
39       this week :)                                                     [20:55]
40<rudi> I have a fix similar to the #.(find-package ...) one, for single-and
41       double-float NaNs
42<easye> Good.  Erik has fixed a number of problems in CLOS.  Maybe they were
43        edge cases.   
44<easye> But I presume you have been reviewing the commits.              [20:56]
45<rudi> only cursorily.. internet prices in Swiss hotels are hacker-unfriendly
46<easye> Prices in Switzerland in general are benefiting only the moneyed
47        hacker.                                                         [20:57]
48<rudi> well, I do live in Norway ...
49<easye> There gotta be a market for someone to arbitrage basic IP on a 3G for
50        a cheaper roaming rate.                                         [20:58]
51<rudi> depending on the usage scenario, cellphone roaming might have been
52       cheaper, actually                                                [20:59]
53<rudi> grepping for '"#.(' turned up less than I expected, but readable NaNs
54       should now be robust against package and reader weirdness        [21:03]
55<easye> Does this deal with Stas' reported problem?                     [21:18]
56<easye> Probably not.                                                   [21:20]
57<rudi> no, I just saw the s/fnd-package/cl:find-package/ and thought "hey, I
58       bet we do this elsewhere as well"                                [21:23]
59<easye> Right.                                                          [21:24]
60<easye> So, how does stuff depending on CLOSER-MOP in Quicklisp actually do
61        with abcl-1.1.0-dev at this point?
62ERC> /topic
63     http://trac.common-lisp.net/armedbear/wiki/releng/abcl-1.1.0/meetings/20120805
64                                                                        [21:25]
65*** easye (~user@213.33.70.157) has set the topic for #abcl:
66    "http://trac.common-lisp.net/armedbear/wiki/releng/abcl-1.1.0/meetings/20120805"
67<V-ille> lots of activity in this scrum :)                              [21:26]
68<rudi> well, closer-mop doesn't support abcl yet - I thought it didn't make
69       sense to send a patch before there's a mop-ful abcl release      [21:27]
70<V-ille> understood
71<rudi> hmm, but I can send a patch to Pascal, see if he's interested in
72       compiling the svn version
73*** rudi (~rudi@cm-84.208.89.228.getinternet.no) has quit: Quit: Computer has
74    gone to sleep.
75<V-ille> sounds good, that, too
76<easye> Well, if you just circulate the patch to the Quicklisp code, we could
77        all check it out...                                             [21:29]
78<easye> I think you have: I just need to hunt it down.                  [21:30]
79*** stassats` (~stassats@wikipedia/stassats) has joined channel #abcl   [21:31]
80* easye has spent a bit of time figuring out what it would take to create an
81  ABCL specific Quicklisp distribution.                                 [21:34]
82<easye> This would be a copy of some baseline "upstream" Quicklisp from Xach,
83        but with diffs applied for ABCL specific features that haven't made it
84        to the individual distributions.                                [21:35]
85<easye> I estimate it would take about twenty hours of work to get an initial
86        version working.
87<easye> I already have the requisite AMZN S3 account, but Xach has a lot of
88        privately held tooling to actually grind a "quicklisp" release.  Not
89        that this is greedy of Xach, as I think he is still refactoring things
90        as they make sense and that he really wants to export stable APIs.
91                                                                        [21:37]
92<easye> As a quickie mechanism, since Quicklisp is almost always a known
93        pathname local to the $HOME directory, it is quite easy to create
94        diffs that one can apply to an existing Quicklisp installation. 
95                                                                        [21:39]
96<easye> The quickie mechanism only "lasts" until the next Quicklisp update.
97<stassats`> any comments on my patches which make drakma work?
98<easye> But maybe it makes some sense to advance the "abcl" Quicklisp
99        distribution idea as we get closer to shipping abcl-1.1.0 so we can
100        all test from a known base.                                     [21:40]
101<easye> stassats`: On the mailing list?
102<stassats`> yes
103* easye takes it as a point to follow up.
104*** rudi (~rudi@cm-84.208.89.228.getinternet.no) has joined channel #abcl
105*** ChanServ (ChanServ@services.) has changed mode for #abcl to +o rudi
106<V-ille> it looked sane to me                                           [21:41]
107<rudi> got disconnected without noticing ... what did I miss?
108<stassats`> it's a trivial issue, but maybe it could be made in some another
109            place
110<stassats`> e.g. when creating the stream
111<V-ille> rudi: I like the idea of pushing the closer-mop patch to Pascal
112         before the release                                             [21:42]
113<rudi> I just decided I'll add :mop to *features* and use that in the patch
114<stassats`> e.g. (deftype octet () '(unsigned-byte 8)) => (with-open-file (foo
115            "/dev/zero" :element-type 'octet) (stream-element-type foo))
116            (UNSIGNED-BYTE 8)                                           [21:43]
117<stassats`> something like that could be made for gray streams
118<easye> rudi: http://paste.lisp.org/display/130887
119<rudi> thx                                                              [21:44]
120<easye> rudi:  essentially we need to track down your patch to closer-mop,
121        creating a version that works against the current Quicklisp
122<rudi> didn't write it yet - there's one for mop-feature-tests though   [21:45]
123<easye> Right.                                                          [21:46]
124<rudi> but quicklisp is a reason to write it asap; I don't know how fast
125       Pascal is with merging patches these days
126<rudi> (or does anyone else have commit rights for closer-mop?)
127<easye> One can fairly easily create a patch wrt $HOME that will easily patch
128        any Quicklisp installed on a non-MSFT Windows platform.         [21:47]
129<rudi> right
130<stassats`> and another issue, i can't load cffi, it complains about not being
131            able to create / when accessing jar, let me get the exact message
132                                                                        [21:48]
133<stassats`> Error while trying to load definition for system jna from pathname
134            jar:file:/home/stas/lisp/impl/abcl/dist/abcl-contrib.jar!/mvn/jna.asd:
135            Can't create directory /.
136* easye needs lots of examples of where loading CFFI fails.
137<easye> stassats`: AH.  That's what I've been looking at all week.      [21:49]
138<stassats`> good
139<easye> What is your os/hardware/jdk combination?
140<stassats`> debian, openjdk-6
141* easye only sees a failure on x86_64-solaris-5.11 running orcl-jdk-1.[67]
142<stassats`> i can try openjdk-7                                         [21:50]
143<easye> Well, it is good to know that I am not chasing a local problem.
144        Thanks!
145<easye> I'll note that I need to file a ticket on this for you.
146<stassats`> same thing on 64-bit openjdk 7                              [21:51]
147<easye> stassats`: Have you tried (handler-case                         [21:52]
148<easye>     (progn
149<easye>       (require :abcl-contrib)
150<easye>       (require :jna))
151<easye>   (t (condition)
152<easye>     (progn
153<easye>       (warn "~&For Lisp implementation version: ~S~&Failed to load JNA
154        via ABCL-CONTRIB on because: ~S~%Attempting to monkey patch via
155        ABCL-ASDF."
156<easye>             (lisp-implementation-version)
157<easye>             condition)
158<easye>       (require :abcl-asdf)   
159<easye>       (java:add-to-classpath (abcl-asdf:resolve-dependencies
160        "com.sun.jna" "jna" "3.0.9"))
161<easye>       (provide :jna))))
162<rudi> I get the same error on os x.8, jdk 1.6
163<easye> Sorry.  See http://paste.lisp.org/+2SZS
164<easye> I had posted it to the mailing list.                            [21:53]
165<easye> This is just a temporary workaround until I figure out what is going
166        wrong.
167* easye doesn't test enough on openjdk[67]                              [21:54]
168<easye> Anyone know if openjdk[67] runs on OS X easily?
169<rudi> never tried it but:
170       https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port+Project+Status
171                                                                        [21:55]
172<easye> Ok.  I'm looking to "close" the official part of the scrum in five
173        minutes.
174<easye> rudi: Are there OS X binary snapshots?  I've never really been able to
175        build openjdk6 on OS X, as my late-2008 MBP really wheezes too long to
176        figure out the build errros.                                    [21:57]
177<stassats`> easye: fails to load abcl-asdf                              [21:58]
178<stassats`> java.lang.ClassCastException: org.armedbear.lisp.Nil cannot be
179            cast to org.armedbear.lisp.Pathname                         [21:59]
180<easye> It seems like the Mac OS X port preview link doesn't resolve.
181<rudi> the end of https://wikis.oracle.com/display/OpenJDK/Mac+OS+X+Port seems
182       to have a pointer to the goods
183<easye> stassats`:  Ok.  Thanks for trying.
184<easye> Another data point helps.
185<stassats`> easye: http://paste.lisp.org/display/130888#1               [22:00]
186<easye> Like I said, I thought that this was maybe some sort of private error,
187        so it is very good to have replication.
188<easye> And in fact, that is a much more promising looking stacktrace than
189        anything I have been able to get...                             [22:01]
190<easye> Ok.  Closing the log here. 
191<easye> Thanks for everyone's participation.
192<easye> rudi:  Ok if I put you down for publishing links to closer-mop and
193        closer-mop-features patches to Quicklisp?                       [22:02]
194ERC> /topic Armed Bear Common Lisp // abcl-1.0.1 // abcl-1.1.0-dev all day,
195     all week
196*** easye (~user@213.33.70.157) has set the topic for #abcl: "Armed Bear
197    Common Lisp // abcl-1.0.1 // abcl-1.1.0-dev all day, all week"
198<rudi> put me down for patches to support closer-mop, conditionalized on
199       #+(and abcl mop) so they can be merged asap                      [22:03]
200<easye> Gotcha.