From: Alan R. <ala...@gm...> - 2006-01-10 04:23:18
Attachments:
invoke.lisp
|
I don't like having to know the type of things, nor do I like worrying about imports. So I adopted invoke.java from jscheme to implement dynamic dispatch in abcl. There's more to do for this, and to clean up, but I'm using it already (it uses itself too) and figured I'd like to push it out, see if it's any interest from others and get some feedback before doing more work on it. I'm sure there is much room for improvement - most of what I've used from Java is from googling this or that to make something work, so there may be better or more efficient ways of doing things. Please let me know. -Alan |
From: Alan R. <al...@pl...> - 2006-01-10 06:25:11
|
BTW, I have noticed that on occasion repeated calls to do-auto-imports will grow the size of the hash tables *class-name-to-full* and *class-name-to-full-case-insensitive*. Upon examination it appears that there are duplicate entries for the same keys. (there shouldn't be since the keys are strings and the hash tables are equal and equalp hash tables respectively) I haven't been able to create a smaller test cases, unfortunately. -Alan |
From: Peter G. <pe...@ar...> - 2006-01-11 14:23:36
|
On Tue, 10 Jan 2006 at 01:25:34 -0500, Alan Ruttenberg wrote: > BTW, I have noticed that on occasion repeated calls to do-auto-imports > will grow the size of the hash tables *class-name-to-full* and > *class-name-to-full-case-insensitive*. Upon examination it appears that > there are duplicate entries for the same keys. (there shouldn't be > since the keys are strings and the hash tables are equal and equalp > hash tables respectively) I haven't been able to create a smaller test > cases, unfortunately. This certainly sounds like a bug, but I've never seen it myself. I took a look at the relevant code this morning, and nothing seemed obviously wrong. Do you have a reproducible scenario (even one that isn't small)? -Peter |
From: Alan R. <ala...@gm...> - 2006-01-11 21:52:09
|
Did you try loading invoke.java and then calling (do-auto-imports) a few times? Check *class-name-to-full* after each. It shouldn't grow. I don't have any other case than that, but I will try to narrow it when I have a chance. -Alan On Jan 11, 2006, at 9:23 AM, Peter Graves wrote: > On Tue, 10 Jan 2006 at 01:25:34 -0500, Alan Ruttenberg wrote: >> BTW, I have noticed that on occasion repeated calls to do-auto- >> imports >> will grow the size of the hash tables *class-name-to-full* and >> *class-name-to-full-case-insensitive*. Upon examination it appears >> that >> there are duplicate entries for the same keys. (there shouldn't be >> since the keys are strings and the hash tables are equal and equalp >> hash tables respectively) I haven't been able to create a smaller >> test >> cases, unfortunately. > > This certainly sounds like a bug, but I've never seen it myself. I > took > a look at the relevant code this morning, and nothing seemed obviously > wrong. > > Do you have a reproducible scenario (even one that isn't small)? > > -Peter > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through > log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD > SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > armedbear-j-devel mailing list > arm...@li... > https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel |
From: Peter G. <pe...@ar...> - 2006-01-12 02:01:49
|
On Wed, 11 Jan 2006 at 16:51:57 -0500, Alan Ruttenberg wrote: > Did you try loading invoke.java and then calling (do-auto-imports) a > few times? Check *class-name-to-full* > after each. It shouldn't grow. > > I don't have any other case than that, but I will try to narrow it > when I have a chance. OK, I've reproduced the problem, which seems to only occur with EQUALP hash tables (*CLASS-NAME-TO-FULL-CASE-INSENSITIVE*, in this case). One thing: for your code to work with CVS ABCL as well as 0.0.9, the test at the top of ARGVS needs to be changed from: (let ((res (jcall-raw get argvs))) (if (equal res null) ... to (let ((res (jcall-raw get argvs))) (if (or (null res) (equal res null)) In CVS, JCALL-RAW returns NIL if the call returns null, rather than JavaObject(null). (I'm not sure if this was a slip or a deliberate change; either approach seems reasonable.) Now I'm off to fix EQUALP hash tables... -Peter |
From: Andras S. <as...@ma...> - 2006-01-12 02:27:22
|
On Wed, 11 Jan 2006, Peter Graves wrote: > One thing: for your code to work with CVS ABCL as well as 0.0.9, the > test at the top of ARGVS needs to be changed from: > > (let ((res (jcall-raw get argvs))) > (if (equal res null) > ... > > to > > (let ((res (jcall-raw get argvs))) > (if (or (null res) (equal res null)) > > In CVS, JCALL-RAW returns NIL if the call returns null, rather than > JavaObject(null). (I'm not sure if this was a slip or a deliberate > change; either approach seems reasonable.) I didn't notice this change at the time (seems to have happened between 1.53 and 1.54) but now that you point it out, let me complain loudly :) It's not just about consistency: the point of *-raw is that their result can be passed back to java without further massaging. Am I missing something? Andras |
From: Peter G. <pe...@ar...> - 2006-01-12 03:59:53
|
On Wed, 11 Jan 2006 at 18:01:42 -0800, Peter Graves wrote: > Now I'm off to fix EQUALP hash tables... Now fixed in CVS. The put() and remove() methods were using equals() instead of equalp() as the test. Thanks for reporting this problem! -Peter |
From: Alan R. <ala...@gm...> - 2006-01-12 04:48:47
|
Can't quite see how this would fix things. The thing is that the symptom is that once all the keys are in the table, even with this change, how would a duplicate key be added? -Alan On Jan 11, 2006, at 10:59 PM, Peter Graves wrote: > On Wed, 11 Jan 2006 at 18:01:42 -0800, Peter Graves wrote: >> Now I'm off to fix EQUALP hash tables... > > Now fixed in CVS. > > The put() and remove() methods were using equals() instead of equalp() > as the test. > > Thanks for reporting this problem! > > -Peter > |
From: Peter G. <pe...@ar...> - 2006-01-12 06:53:34
|
On Wed, 11 Jan 2006 at 23:49:16 -0500, Alan Ruttenberg wrote: > Can't quite see how this would fix things. The thing is that the > symptom is that once all the keys are in the table, even with this > change, how would a duplicate key be added? When you call SETF GEHASH, you're really calling EqualpHashTable.put(), which checks to see if there is already a key in the table that matches according to the test. If a match is found, the new value replaces the old value associated with the existing key, and the table does not grow. However, if the test is Object.equals(), which amounts to EQ, the match will only happen if you're using the same exact object as the key. This won't be the case, since SUBSTRING always returns a freshly allocated string. So a new entry will be created in the table for the "new" key, and the table grows. Changing Object.equals() to LispObject.equalp() is, in effect, changing the test from EQ to EQUALP. With this change, the existing key will be identified correctly as matching the key passed in, and the entry will be reused. The waters were muddied a bit more because put() and remove() had the equals() bug, but get() did not; it used equalp() from the beginning, so retrievals worked correctly. -Peter |
From: Alan R. <ala...@gm...> - 2006-01-12 13:22:54
|
On Jan 12, 2006, at 1:53 AM, Peter Graves wrote: > On Wed, 11 Jan 2006 at 23:49:16 -0500, Alan Ruttenberg wrote: >> Can't quite see how this would fix things. The thing is that the >> symptom is that once all the keys are in the table, even with this >> change, how would a duplicate key be added? > > However, if the test is Object.equals(), which amounts to EQ, the > match > will only happen if you're using the same exact object as the key. Ah. This was the part I was missing. I didn't understand that Object.equals amounted to EQ. I read it that you were correcting EQUAL to EQUALP. Thanks, Alan |
From: Peter G. <pe...@ar...> - 2006-01-11 14:20:47
|
On Mon, 9 Jan 2006 at 23:23:11 -0500, Alan Ruttenberg wrote: > I don't like having to know the type of things, nor do I like > worrying about imports. So I adopted invoke.java from jscheme to > implement dynamic dispatch in abcl. There's more to do for this, and > to clean up, but I'm using it already (it uses itself too) and > figured I'd like to push it out, see if it's any interest from others > and get some feedback before doing more work on it. > > I'm sure there is much room for improvement - most of what I've used > from Java is from googling this or that to make something work, so > there may be better or more efficient ways of doing things. Please > let me know. This looks pretty cool. I'm glad to see more options starting to emerge for Java FFI with ABCL. (As I've mentioned before, I don't actually _use_ Java FFI myself, so I'm not likely to provide any substantive feedback, but I'm really glad folks are working on this sort of thing.) Thanks! -Peter |
From: Peter G. <pe...@ar...> - 2006-01-12 02:51:58
|
On Thu, 12 Jan 2006 at 03:27:12 +0100, Andras Simon wrote: > > > On Wed, 11 Jan 2006, Peter Graves wrote: > > > One thing: for your code to work with CVS ABCL as well as 0.0.9, the > > test at the top of ARGVS needs to be changed from: > > > > (let ((res (jcall-raw get argvs))) > > (if (equal res null) > > ... > > > > to > > > > (let ((res (jcall-raw get argvs))) > > (if (or (null res) (equal res null)) > > > > In CVS, JCALL-RAW returns NIL if the call returns null, rather than > > JavaObject(null). (I'm not sure if this was a slip or a deliberate > > change; either approach seems reasonable.) > > I didn't notice this change at the time (seems to have happened > between 1.53 and 1.54) but now that you point it out, let me complain > loudly :) It's not just about consistency: the point of *-raw is that > their result can be passed back to java without further massaging. > > Am I missing something? No, I probably just screwed it up and didn't notice. I'll change it back. Sorry! -Peter |
From: Andras S. <as...@ma...> - 2006-01-12 09:15:57
|
On Wed, 11 Jan 2006, Peter Graves wrote: > On Thu, 12 Jan 2006 at 03:27:12 +0100, Andras Simon wrote: >> >> >> On Wed, 11 Jan 2006, Peter Graves wrote: >> >>> One thing: for your code to work with CVS ABCL as well as 0.0.9, the >>> test at the top of ARGVS needs to be changed from: >>> >>> (let ((res (jcall-raw get argvs))) >>> (if (equal res null) >>> ... >>> >>> to >>> >>> (let ((res (jcall-raw get argvs))) >>> (if (or (null res) (equal res null)) >>> >>> In CVS, JCALL-RAW returns NIL if the call returns null, rather than >>> JavaObject(null). (I'm not sure if this was a slip or a deliberate >>> change; either approach seems reasonable.) >> >> I didn't notice this change at the time (seems to have happened >> between 1.53 and 1.54) but now that you point it out, let me complain >> loudly :) It's not just about consistency: the point of *-raw is that >> their result can be passed back to java without further massaging. >> >> Am I missing something? > > No, I probably just screwed it up and didn't notice. I'll change it > back. Thanks! Andras |