From tomas.hlavaty at knowledgetools.de Thu Jan 21 15:10:46 2010 From: tomas.hlavaty at knowledgetools.de (Tomas Hlavaty) Date: Thu, 21 Jan 2010 16:10:46 +0100 Subject: [Cl-perec-devel] allegro port Message-ID: <86sk9zsdc9.fsf@knowledgetools.de> Hi all, thank you for cl-perec/hu.dwim.perec. I am porting it to allegro and I would like to ask whether you would be interested in portability patches? For start, I published my darcs repositories at: http://www.knowledgetools.de/tmp/temporaer/tomas/hu.dwim.walker/ http://www.knowledgetools.de/tmp/temporaer/tomas/hu.dwim.serializer/ Any feedback is welcome. Thank you, Tomas From levente.meszaros at gmail.com Thu Jan 21 16:05:37 2010 From: levente.meszaros at gmail.com (=?ISO-8859-1?Q?Levente_M=E9sz=E1ros?=) Date: Thu, 21 Jan 2010 17:05:37 +0100 Subject: [Cl-perec-devel] allegro port In-Reply-To: <86sk9zsdc9.fsf@knowledgetools.de> References: <86sk9zsdc9.fsf@knowledgetools.de> Message-ID: On Thu, Jan 21, 2010 at 4:10 PM, Tomas Hlavaty wrote: > Hi all, > > thank you for cl-perec/hu.dwim.perec. ?I am porting it to allegro and I > would like to ask whether you would be interested in portability > patches? ?For start, I published my darcs repositories at: Sure, we are interested and willing to push mainstream as long as we don't have regression in our test suites. BTW, you are a brave man... you will need to go through all the dependencies which is not an easy task. I would expect most of the portability issues in hu.dwim.computed-class and hu.dwim.perec. See the test menu at http://dwim.hu/ for the latest test results. It's updated every night and will include more detailed info. Actually we could even set up Allegro if we would have a licence which is good enough to run the test suites. This would allow comparing the results against SBCL. > ? http://www.knowledgetools.de/tmp/temporaer/tomas/hu.dwim.walker/ > ? http://www.knowledgetools.de/tmp/temporaer/tomas/hu.dwim.serializer/ I can't read those repos, I get: Forbidden You don't have permission to access /tmp/temporaer/tomas/hu.dwim.serializer/ on this server. levy -- There's no perfectoin From tomas.hlavaty at knowledgetools.de Thu Jan 21 16:41:12 2010 From: tomas.hlavaty at knowledgetools.de (Tomas Hlavaty) Date: Thu, 21 Jan 2010 17:41:12 +0100 Subject: [Cl-perec-devel] allegro port In-Reply-To: ("Levente =?utf-8?B?TcOpc3rDoXJvcyIncw==?= message of "Thu, 21 Jan 2010 17:05:37 +0100") References: <86sk9zsdc9.fsf@knowledgetools.de> Message-ID: <86fx5zs95j.fsf@knowledgetools.de> Hi Levy, thanks for your quick reply. > Sure, we are interested and willing to push mainstream as long as we > don't have regression in our test suites. I don't plan breaking any of the existing sbcl test;-) There are some tests that don't work for me on sbcl with the mainstream code but I ignore those for porting purposes. > BTW, you are a brave man... you will need to go through all the > dependencies which is not an easy task. I would expect most of the > portability issues in hu.dwim.computed-class and hu.dwim.perec. I have hu.dwim.computed-class working now. I haven't published the fixes yet but I plan to do so tomorrow. HU.DWIM.WALKER.TEST::TEST/SEMANTICS/TYPES/1 fails on allegro due to my broken global-variable-type-in-lexenv, but as the function is rather new I guess it is not that important with regard to perec yet. > Actually we could even set up Allegro if we would have a licence which > is good enough to run the test suites. This would allow comparing the > results against SBCL. That would be nice but I am not sure how to go about it at the moment. > I can't read those repos, I get: Does darcs get http://www.knowledgetools.de/tmp/temporaer/tomas/hu.dwim.walker/ darcs get http://www.knowledgetools.de/tmp/temporaer/tomas/hu.dwim.serializer/ work for you? Thank you, Tomas From attila.lendvai at gmail.com Thu Jan 21 17:59:14 2010 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Thu, 21 Jan 2010 18:59:14 +0100 Subject: [Cl-perec-devel] allegro port In-Reply-To: <86fx5zs95j.fsf@knowledgetools.de> References: <86sk9zsdc9.fsf@knowledgetools.de> <86fx5zs95j.fsf@knowledgetools.de> Message-ID: > darcs get http://www.knowledgetools.de/tmp/temporaer/tomas/hu.dwim.walker/ > darcs get http://www.knowledgetools.de/tmp/temporaer/tomas/hu.dwim.serializer/ i've pushed most of your changes, and a bit of cleanup here and there. please pull and test them (and possibly un-break them again on allegro :) one thing that may be broken is #.(values) possibly reading into NIL instead of nothing as on sbcl. thanks, looking forward for the rest of the changes! -- attila ps: David Lichteblau mentined that they (you?) are working on a port to Allegro. i assume you are his colleague, Tomas? From tomas.hlavaty at knowledgetools.de Fri Jan 22 13:09:23 2010 From: tomas.hlavaty at knowledgetools.de (Tomas Hlavaty) Date: Fri, 22 Jan 2010 14:09:23 +0100 Subject: [Cl-perec-devel] allegro port In-Reply-To: (Attila Lendvai's message of "Thu, 21 Jan 2010 18:59:14 +0100") References: <86sk9zsdc9.fsf@knowledgetools.de> <86fx5zs95j.fsf@knowledgetools.de> Message-ID: <86vdeuqoak.fsf@knowledgetools.de> Hi Attila, > i've pushed most of your changes, and a bit of cleanup here and there. > please pull and test them (and possibly un-break them again on allegro thank you! > one thing that may be broken is #.(values) possibly reading into NIL > instead of nothing as on sbcl. I've tried the serializer and it works on allegro. > thanks, looking forward for the rest of the changes! I have published a few more darcs repositories with new patches. The list is at http://www.knowledgetools.de/tmp/temporaer/tomas/index.html. serializer, walker, computed-class and rdbms/postgresql-backend work on allegro now. More will come;-) > ps: David Lichteblau mentined that they (you?) are working on a port > to Allegro. i assume you are his colleague, Tomas? Yes, I work with David. He started the allegro port originally. Cheers, Tomas From attila.lendvai at gmail.com Tue Jan 26 10:41:56 2010 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Tue, 26 Jan 2010 11:41:56 +0100 Subject: [Cl-perec-devel] allegro port In-Reply-To: <86vdeuqoak.fsf@knowledgetools.de> References: <86sk9zsdc9.fsf@knowledgetools.de> <86fx5zs95j.fsf@knowledgetools.de> <86vdeuqoak.fsf@knowledgetools.de> Message-ID: thanks for the patches Tomas! drop me a note when you have more to pull from those repos! i've realized that due to a mistake on my part the repos at dwim.hu are not darcs2 format, only darcs1 hashed. i'm planning to convert them this weekend, so please if you have any patches/changes then push them to your repos! after the conversion, users will have to darcs get the new darcs2 repos, because patches can not travel between darcs1 and darcs2 repos. or if you are in the middle of something bigger, then i can delay this... -- attila From tomas.hlavaty at knowledgetools.de Wed Jan 27 11:14:30 2010 From: tomas.hlavaty at knowledgetools.de (Tomas Hlavaty) Date: Wed, 27 Jan 2010 12:14:30 +0100 Subject: [Cl-perec-devel] allegro port In-Reply-To: (Attila Lendvai's message of "Tue, 26 Jan 2010 11:41:56 +0100") References: <86sk9zsdc9.fsf@knowledgetools.de> <86fx5zs95j.fsf@knowledgetools.de> <86vdeuqoak.fsf@knowledgetools.de> Message-ID: <86wrz3pzop.fsf@knowledgetools.de> Hi Attila, > are not darcs2 format, only darcs1 hashed. i'm planning to convert > them this weekend, so please if you have any patches/changes then push > them to your repos! OK, I will commit a few things by the end of the week. Cheers, Tomas From tomas.hlavaty at knowledgetools.de Fri Jan 29 11:33:49 2010 From: tomas.hlavaty at knowledgetools.de (Tomas Hlavaty) Date: Fri, 29 Jan 2010 12:33:49 +0100 Subject: [Cl-perec-devel] allegro port In-Reply-To: (Attila Lendvai's message of "Tue, 26 Jan 2010 11:41:56 +0100") References: <86sk9zsdc9.fsf@knowledgetools.de> <86fx5zs95j.fsf@knowledgetools.de> <86vdeuqoak.fsf@knowledgetools.de> Message-ID: <86sk9pcfhe.fsf@knowledgetools.de> Hi Attila, > drop me a note when you have more to pull from those repos! I have updated the repositories at http://www.knowledgetools.de/tmp/temporaer/tomas/index.html with new patches. (Note that hu.dwim.perec repository is currently broken, see below.) I've got cl-perec to work on allegro, but when I switched to hu.dwim.perec, there is one problem I haven't figured out yet. The patch to port slot-definition-class is in the above repo and it works with cl-perec but not with hu.dwim.perec (broken both on sbcl and allegro). Basically, I replaced sb-pcl::%class with a new slot in persistent-slot-definition to make it portable. In hu.dwim.perec however, slot-definition-class is called (recursively and) even for non-persistent slots which seems wrong to me. So far, I haven't figured out why exactly, only that when slot-boundp-or-value-using-class is called on a slot, persistent-p is called (which looks at the non-persistent slot 'persistent' of the class persistent-object) and then it fails with There is no applicable method for the generic function # when called with arguments (#). [Condition of type SIMPLE-ERROR] Restarts: 0: [TERMINATE-TRANSACTION] return (values) from the WITH-TRANSACTION block executing the current terminal action :COMMIT 1: [COMMIT-TRANSACTION] mark transaction for commit only and return (values) from the WITH-TRANSACTION block 2: [ROLLBACK-TRANSACTION] mark transaction for rollback only and return (values) from the WITH-TRANSACTION block 3: [RESTART-TRANSACTION] rollback the transaction by unwinding the stack and restart the WITH-TRANSACTION block in a new database transaction 4: [CONTINUE] Skip the rest of the test HU.DWIM.PEREC.TEST::TEST/PERSISTENCE/INSTANCE/MODIFIED/1 and continue by returning (values) 5: [RETEST] Rerun the test HU.DWIM.PEREC.TEST::TEST/PERSISTENCE/INSTANCE/MODIFIED/1 --more-- Backtrace: 0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #) 1: (SWANK::DEBUG-IN-EMACS #) 2: (SWANK:INVOKE-SLIME-DEBUGGER #) 3: (SWANK-BACKEND::CALL-WITH-BREAK-HOOK # #) 4: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) # #) 5: (SWANK:SWANK-DEBUGGER-HOOK # #) 6: (SB-DEBUG::RUN-HOOK *DEBUGGER-HOOK* #) 7: (INVOKE-DEBUGGER #) 8: (HU.DWIM.STEFIL::RECORD-UNEXPECTED-ERROR #) 9: ((FLET #:LAMBDA79) #) 10: (SIGNAL #)[:EXTERNAL] 11: (ERROR "~@")[:EXTERNAL] 12: ((SB-PCL::FAST-METHOD NO-APPLICABLE-METHOD (T)) # # #)[:EXTERNAL] 13: ((SB-PCL::FAST-METHOD SB-MOP:SLOT-VALUE-USING-CLASS (HU.DWIM.PEREC:PERSISTENT-CLASS HU.DWIM.PEREC:PERSISTENT-OBJECT SB-MOP:STANDARD-EFFECTIVE-SLOT-DEFINITION)) #) Locals: SB-DEBUG::ARG-0 = : SB-DEBUG::ARG-1 = # SB-DEBUG::ARG-2 = # SB-DEBUG::ARG-3 = #> {D207AB1}> SB-DEBUG::ARG-4 = # 14: (SLOT-VALUE #) Locals: SB-DEBUG::ARG-0 = #> {D207AB1}> SB-DEBUG::ARG-1 = HU.DWIM.PEREC::PERSISTENT 15: (HU.DWIM.PEREC::SLOT-BOUNDP-OR-VALUE-USING-CLASS #) Locals: SB-DEBUG::ARG-0 = # SB-DEBUG::ARG-1 = #> {D207AB1}> SB-DEBUG::ARG-2 = # SB-DEBUG::ARG-3 = # 16: ((SB-PCL::FAST-METHOD SHARED-INITIALIZE (SB-PCL::SLOT-OBJECT T)) #)[:EXTERNAL] Locals: SB-DEBUG::ARG-0 = 8 SB-DEBUG::ARG-1 = : SB-DEBUG::ARG-2 = : SB-DEBUG::ARG-3 = #> {D207AB1}> SB-DEBUG::ARG-4 = T 17: ((SB-PCL::FAST-METHOD INITIALIZE-INSTANCE :AROUND (HU.DWIM.PEREC:PERSISTENT-OBJECT)) #)[:EXTERNAL] 18: ((SB-PCL::FAST-METHOD MAKE-INSTANCE (CLASS)) # # #)[:EXTERNAL] Isn't it wrong that slot-definition-class is called even for slots that are not persistent? I haven't yet located where this happens so any idea where is this happening would be great help. Thank you, Tomas From tomas.hlavaty at knowledgetools.de Fri Jan 29 15:52:17 2010 From: tomas.hlavaty at knowledgetools.de (Tomas Hlavaty) Date: Fri, 29 Jan 2010 16:52:17 +0100 Subject: [Cl-perec-devel] allegro port In-Reply-To: ("Levente =?utf-8?B?TcOpc3rDoXJvcyIncw==?= message of "Fri, 29 Jan 2010 13:55:20 +0100") References: <86sk9zsdc9.fsf@knowledgetools.de> <86fx5zs95j.fsf@knowledgetools.de> <86vdeuqoak.fsf@knowledgetools.de> <86sk9pcfhe.fsf@knowledgetools.de> Message-ID: <86zl3wc3im.fsf@knowledgetools.de> Hi Levy, > I think this happens in slot-value.lisp at: thanks a lot! > This is a protection against a mismatch in the instance/slot pair. > This would be desirable for standard slots too, but we can get rid of > that, because I don't think we loose that much. I see. I don't know how important this debugging check is. It could stay there on sbcl using sb-pcl::%class as before but then it'd be a bit messy. Another solution could be creating new portable class for non-persistent slots, something like transient-slot-definition and holding the %%class value there although that might be overkill. > If we support this only for persistent classes, then it might be a > good idea to follow the naming convention there instead of the generic > slot-definition-* for standard slots. I guess you mean calling it persistent-slot-definition-class? Regards, Tomas From levente.meszaros at gmail.com Fri Jan 29 16:04:16 2010 From: levente.meszaros at gmail.com (=?ISO-8859-1?Q?Levente_M=E9sz=E1ros?=) Date: Fri, 29 Jan 2010 17:04:16 +0100 Subject: [Cl-perec-devel] allegro port In-Reply-To: <86zl3wc3im.fsf@knowledgetools.de> References: <86sk9zsdc9.fsf@knowledgetools.de> <86fx5zs95j.fsf@knowledgetools.de> <86vdeuqoak.fsf@knowledgetools.de> <86sk9pcfhe.fsf@knowledgetools.de> <86zl3wc3im.fsf@knowledgetools.de> Message-ID: On Fri, Jan 29, 2010 at 4:52 PM, Tomas Hlavaty wrote: > holding the %%class value there although that might be overkill. Just remove that check, I think it's not worth the effort and the complexity. >> If we support this only for persistent classes, then it might be a >> good idea to follow the naming convention there instead of the generic >> slot-definition-* for standard slots. > I guess you mean calling it persistent-slot-definition-class? Yes. levy -- There's no perfectoin