From avodonosov at yandex.ru Thu Jul 14 23:44:40 2011 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Fri, 15 Jul 2011 03:44:40 +0400 Subject: [trivial-gray-streams-devel] [cl-plus-ssl-devel] trivial-gray-streams becomes a separate project In-Reply-To: <154771309006279@web41.yandex.ru> References: <20110615121750.GH7188@radon> <435121308140691@web125.yandex.ru> <20110615205528.GI7188@radon> <943921308650676@web113.yandex.ru> <20110624161834.GA30157@radon> <6486E29B-F30F-4083-8B02-31F90C402EBC@gmail.com> <154771309006279@web41.yandex.ru> Message-ID: <134871310687080@web45.yandex.ru> Hello, Chun Tian, what do you think about all this? Best regards, - Anton 25.06.2011, 16:51, "Anton Vodonosov" : > Hello. > > BTW, there is a trivial-gray-streams-devel list... > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/trivial-gray-streams-devel > > What I understand: > > This code provides Gray streams implementation for MCL and SCL > (these project do not implement the Gray streams proposal) > > So far trivial-gray-streams only provided compatibility layer between > different Gray streams implementations (all the Lisps supported have > Gray streams). trivial-gray-streams only re-export the gray stream function > provided by exisging Lisps from trivial-gray-streams package and make > some fixes/unifications as in case of stream-read-sequence, which is > absent in Gray streams proposal and therefore sometimes is implemented differently > in different lisps. > > If we commit this code, trivial-gray-streams will get somewhat > different purpose - in addition to be a compatibility layer on top > of Gray streams, it will also provide the Gray streams for MCL and SCL. > > Maybe it's better to commit the Gray streams to MCL and SCL... > But if it's problematic, why not commit it to trivial-gray-streams... > at least there will be no incompatibilities between trivial-gray-stream > and MCL/SCL Gray streams (but we will need to care about > compatibility between MCL/SCL Gray streams and MCL/SCL internals > used in the Gray streams implementation). > > Have you tried to suggest the Gray streams implementation to MCL and SCL? > > I don't have MCL (and mac to run it), and I can't say I read and understood every line > of the code, but if you say the code works... > > Could you explain the issue pointed by Daniel, when the gray stream function calls a > function from CCL package, and the function in the CCL package calls the Gray streams > function? How it is resolved? By inheriting from fundamental-stream and redefining > one of the functions or how? > > (defmethod stream-file-position ((stream fundamental-stream)) > ??(ccl:stream-position stream)) > > (defmethod (setf stream-file-position) (position (stream fundamental-stream)) > ??(ccl:stream-position stream position)) > > (defmethod ccl:stream-position ((stream fundamental-stream) &optional position) > ??(if position > ????(setf (stream-file-position stream) position) > ????(stream-file-position stream))) > > Best regards, > - Anton > > 25.06.2011, 15:58, "Chun Tian (binghe)" ;: > >> ?A updated version of mcl-gray-streams.lisp which could make chunga work on MCL, it replaces CLOSE and OPEN-STREAM-P into generic functions. >> >> ?? 2011-6-25?13:53? Chun Tian (binghe) ??? >>> ??Hi, David >>> >>> ??I'm not sure, but I think it's possible to change MCL's any behavior by just loading new code into it, to make it looking like having native support of Gray Streams. >>> >>> ??And I think the whole purpose is just to make those packages which depends on trivial-gray-streams running well on MCL, and I'll try to analyze any issue in this process and figure out a solution to fix it. >>> >>> ??For example, today, when I can try to load Chunga (depend by Hunchentoot) into MCL, I found it try to define a method on OPEN-STREAM-P, which is a standard CL ordinary function but generic function in MCL: >>> >>> ??(defmethod open-stream-p ((stream chunked-stream)) >>> ???"A chunked stream is open if its underlying stream is open." >>> ???(open-stream-p (chunked-stream-stream stream))) >>> >>> ??To make above code runs on MCL, MCL's own function OPEN-STREAM-P need to be overridden, and this is quite possible and I'm just working on it. >>> >>> ??Any way, I hope my initial work being merged first to have a base point, and then people like you and me could have more patches to fix any rest issue in it. >>> >>> ??--binghe >>> >>> ??? 2011-6-25?00:18? David Lichteblau ??? >>>> ??Quoting Chun Tian (binghe) (binghe.lisp at gmail.com): >>>>> ??The MCL support code was written by Terje Norderhaug with my little >>>>> ??modifications, it's partly confirmed by my own projects which depend on >>>>> ??trivial-gray-streams and running on MCL; ?the SCL support code is from IOlib >>>>> ??project, untested (because I don't have a valid license), but I believe it >>>>> ??should work, at least no harm to other platforms. >>>> ??Cool, thanks. ?Quick feedback: >>>> >>>> ??It looks to me like many definitions are recursive, i.e. the gray >>>> ??streams methods call MCL internals, which call gray steams methods. >>>> >>>> ??trivial-gray-streams does not attempt to offer user code the ability to >>>> ??call low-level STREAM-foo functions. ?Rather, it aims to allows stream >>>> ??implementors to define STREAM-foo methods such that the CL stream system >>>> ??will end up calling that implementation. >>>> >>>> ??I.e. the method CCL:STREAM-POSITION seems correct in calling >>>> ??STREAM-FILE-POSITION, but the reverse method on STREAM-FILE-POSITION >>>> ??that calls CCL:STREAM-POSITION is meaningless and should either say >>>> ??(error "not implemented") >>>> ??or the method could be left out entirely, leaving it to the Lisp to >>>> ??signal the condition that no method is applicable. >>>> >>>> ??(If I'm reading the code right.) >>>> >>>> ??d. >>>> >>>> ??_______________________________________________ >>>> ??cl-plus-ssl-devel mailing list >>>> ??cl-plus-ssl-devel at common-lisp.net >>>> ??http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cl-plus-ssl-devel >> ?_______________________________________________ >> ?cl-plus-ssl-devel mailing list >> ?cl-plus-ssl-devel at common-lisp.net >> ?http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cl-plus-ssl-devel > > _______________________________________________ > trivial-gray-streams-devel mailing list > trivial-gray-streams-devel at common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/trivial-gray-streams-devel From binghe.lisp at gmail.com Fri Jul 15 01:14:50 2011 From: binghe.lisp at gmail.com (Chun Tian (binghe)) Date: Fri, 15 Jul 2011 09:14:50 +0800 Subject: [trivial-gray-streams-devel] [cl-plus-ssl-devel] trivial-gray-streams becomes a separate project In-Reply-To: <134871310687080@web45.yandex.ru> References: <20110615121750.GH7188@radon> <435121308140691@web125.yandex.ru> <20110615205528.GI7188@radon> <943921308650676@web113.yandex.ru> <20110624161834.GA30157@radon> <6486E29B-F30F-4083-8B02-31F90C402EBC@gmail.com> <154771309006279@web41.yandex.ru> <134871310687080@web45.yandex.ru> Message-ID: <2E5005F3-5650-453F-8A0F-92248C0BCE43@gmail.com> Hi, Anton I'm a little busy these days in other Lisp projects. I still believe the MCL/SCL support code works, I'll prove this in short future. If no others help me on this, I suggest holding this issue for now. Regards, Chun Tian (binghe) ? 2011-7-15?07:44? Anton Vodonosov ??? > Hello, > > Chun Tian, what do you think about all this? > > Best regards, > - Anton > > 25.06.2011, 16:51, "Anton Vodonosov" : >> Hello. >> >> BTW, there is a trivial-gray-streams-devel list... >> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/trivial-gray-streams-devel >> >> What I understand: >> >> This code provides Gray streams implementation for MCL and SCL >> (these project do not implement the Gray streams proposal) >> >> So far trivial-gray-streams only provided compatibility layer between >> different Gray streams implementations (all the Lisps supported have >> Gray streams). trivial-gray-streams only re-export the gray stream function >> provided by exisging Lisps from trivial-gray-streams package and make >> some fixes/unifications as in case of stream-read-sequence, which is >> absent in Gray streams proposal and therefore sometimes is implemented differently >> in different lisps. >> >> If we commit this code, trivial-gray-streams will get somewhat >> different purpose - in addition to be a compatibility layer on top >> of Gray streams, it will also provide the Gray streams for MCL and SCL. >> >> Maybe it's better to commit the Gray streams to MCL and SCL... >> But if it's problematic, why not commit it to trivial-gray-streams... >> at least there will be no incompatibilities between trivial-gray-stream >> and MCL/SCL Gray streams (but we will need to care about >> compatibility between MCL/SCL Gray streams and MCL/SCL internals >> used in the Gray streams implementation). >> >> Have you tried to suggest the Gray streams implementation to MCL and SCL? >> >> I don't have MCL (and mac to run it), and I can't say I read and understood every line >> of the code, but if you say the code works... >> >> Could you explain the issue pointed by Daniel, when the gray stream function calls a >> function from CCL package, and the function in the CCL package calls the Gray streams >> function? How it is resolved? By inheriting from fundamental-stream and redefining >> one of the functions or how? >> >> (defmethod stream-file-position ((stream fundamental-stream)) >> (ccl:stream-position stream)) >> >> (defmethod (setf stream-file-position) (position (stream fundamental-stream)) >> (ccl:stream-position stream position)) >> >> (defmethod ccl:stream-position ((stream fundamental-stream) &optional position) >> (if position >> (setf (stream-file-position stream) position) >> (stream-file-position stream))) >> >> Best regards, >> - Anton >> >> 25.06.2011, 15:58, "Chun Tian (binghe)" ;: >> >>> A updated version of mcl-gray-streams.lisp which could make chunga work on MCL, it replaces CLOSE and OPEN-STREAM-P into generic functions. >>> >>> ? 2011-6-25?13:53? Chun Tian (binghe) ??? >>>> Hi, David >>>> >>>> I'm not sure, but I think it's possible to change MCL's any behavior by just loading new code into it, to make it looking like having native support of Gray Streams. >>>> >>>> And I think the whole purpose is just to make those packages which depends on trivial-gray-streams running well on MCL, and I'll try to analyze any issue in this process and figure out a solution to fix it. >>>> >>>> For example, today, when I can try to load Chunga (depend by Hunchentoot) into MCL, I found it try to define a method on OPEN-STREAM-P, which is a standard CL ordinary function but generic function in MCL: >>>> >>>> (defmethod open-stream-p ((stream chunked-stream)) >>>> "A chunked stream is open if its underlying stream is open." >>>> (open-stream-p (chunked-stream-stream stream))) >>>> >>>> To make above code runs on MCL, MCL's own function OPEN-STREAM-P need to be overridden, and this is quite possible and I'm just working on it. >>>> >>>> Any way, I hope my initial work being merged first to have a base point, and then people like you and me could have more patches to fix any rest issue in it. >>>> >>>> --binghe >>>> >>>> ? 2011-6-25?00:18? David Lichteblau ??? >>>>> Quoting Chun Tian (binghe) (binghe.lisp at gmail.com): >>>>>> The MCL support code was written by Terje Norderhaug with my little >>>>>> modifications, it's partly confirmed by my own projects which depend on >>>>>> trivial-gray-streams and running on MCL; the SCL support code is from IOlib >>>>>> project, untested (because I don't have a valid license), but I believe it >>>>>> should work, at least no harm to other platforms. >>>>> Cool, thanks. Quick feedback: >>>>> >>>>> It looks to me like many definitions are recursive, i.e. the gray >>>>> streams methods call MCL internals, which call gray steams methods. >>>>> >>>>> trivial-gray-streams does not attempt to offer user code the ability to >>>>> call low-level STREAM-foo functions. Rather, it aims to allows stream >>>>> implementors to define STREAM-foo methods such that the CL stream system >>>>> will end up calling that implementation. >>>>> >>>>> I.e. the method CCL:STREAM-POSITION seems correct in calling >>>>> STREAM-FILE-POSITION, but the reverse method on STREAM-FILE-POSITION >>>>> that calls CCL:STREAM-POSITION is meaningless and should either say >>>>> (error "not implemented") >>>>> or the method could be left out entirely, leaving it to the Lisp to >>>>> signal the condition that no method is applicable. >>>>> >>>>> (If I'm reading the code right.) >>>>> >>>>> d. >>>>> >>>>> _______________________________________________ >>>>> cl-plus-ssl-devel mailing list >>>>> cl-plus-ssl-devel at common-lisp.net >>>>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cl-plus-ssl-devel >>> _______________________________________________ >>> cl-plus-ssl-devel mailing list >>> cl-plus-ssl-devel at common-lisp.net >>> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cl-plus-ssl-devel >> >> _______________________________________________ >> trivial-gray-streams-devel mailing list >> trivial-gray-streams-devel at common-lisp.net >> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/trivial-gray-streams-devel From avodonosov at yandex.ru Fri Jul 15 06:18:06 2011 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Fri, 15 Jul 2011 10:18:06 +0400 Subject: [trivial-gray-streams-devel] gray-treams for MCL and SCL (was: trivial-gray-streams becomes a separate project) In-Reply-To: <2E5005F3-5650-453F-8A0F-92248C0BCE43@gmail.com> References: <20110615121750.GH7188@radon> <435121308140691@web125.yandex.ru> <20110615205528.GI7188@radon> <943921308650676@web113.yandex.ru> <20110624161834.GA30157@radon> <6486E29B-F30F-4083-8B02-31F90C402EBC@gmail.com> <154771309006279@web41.yandex.ru> <134871310687080@web45.yandex.ru> <2E5005F3-5650-453F-8A0F-92248C0BCE43@gmail.com> Message-ID: <274571310710686@web17.yandex.ru> Ok, lets hold it for a while, because I am also bit busy now. Best regards, - Anton 15.07.2011, 05:14, "Chun Tian (binghe)" : > Hi, Anton > > I'm a little busy these days in other Lisp projects. I still believe the MCL/SCL support code works, I'll prove this in short future. If no others help me on this, I suggest holding this issue for now. > > Regards, > > Chun Tian (binghe) > From avodonosov at yandex.ru Fri Jul 15 13:33:32 2011 From: avodonosov at yandex.ru (Anton Vodonosov) Date: Fri, 15 Jul 2011 17:33:32 +0400 Subject: [trivial-gray-streams-devel] gray-treams for MCL and SCL (was: trivial-gray-streams becomes a separate project) In-Reply-To: <274571310710686@web17.yandex.ru> References: <20110615121750.GH7188@radon> <435121308140691@web125.yandex.ru> <20110615205528.GI7188@radon> <943921308650676@web113.yandex.ru> <20110624161834.GA30157@radon> <6486E29B-F30F-4083-8B02-31F90C402EBC@gmail.com> <154771309006279@web41.yandex.ru> <134871310687080@web45.yandex.ru> <2E5005F3-5650-453F-8A0F-92248C0BCE43@gmail.com> <274571310710686@web17.yandex.ru> Message-ID: <448951310736812@web58.yandex.ru> BTW, the main question is not to test the code works (As far as I understand you already tested it in the past). Lets decide, if this code should be committed to trivial-gray-streams, or to MCL/SCL. To me it looks like the latter is more appropriate, because gray streams is a way to extend system functions like READ-CHAR, CLOSE, etc to work with user-defined streams. Therefore the extension interface should come with the implementation of READ-CHAR, CLOSE, etc. Also, if the code relies on, or needs to modify MCL/SCL internals (is it valid to redefine COMMON-LISP:OPEN-STREAM-P to be generic function, while in MC it is a usual function), it is another argument for committing the code to MCL/SCL Best regards, - Anton 15.07.2011, 10:33, "Anton Vodonosov" ;: > ?Ok, lets hold it for a while, because I am also bit busy now. > > ?Best regards, > ?- Anton > > ?15.07.2011, 05:14, "Chun Tian (binghe)" ;;: >> ??Hi, Anton >> >> ??I'm a little busy these days in other Lisp projects. I still believe the MCL/SCL support code works, I'll prove this in short future. If no others help me on this, I suggest holding this issue for now. >> >> ??Regards, >> >> ??Chun Tian (binghe) > ?_______________________________________________ > ?trivial-gray-streams-devel mailing list > ?trivial-gray-streams-devel at common-lisp.net > ?http://lists.common-lisp.net/cgi-bin/mailman/listinfo/trivial-gray-streams-devel From binghe.lisp at gmail.com Fri Jul 15 13:48:08 2011 From: binghe.lisp at gmail.com (Chun Tian (binghe)) Date: Fri, 15 Jul 2011 21:48:08 +0800 Subject: [trivial-gray-streams-devel] gray-treams for MCL and SCL (was: trivial-gray-streams becomes a separate project) In-Reply-To: <448951310736812@web58.yandex.ru> References: <20110615121750.GH7188@radon> <435121308140691@web125.yandex.ru> <20110615205528.GI7188@radon> <943921308650676@web113.yandex.ru> <20110624161834.GA30157@radon> <6486E29B-F30F-4083-8B02-31F90C402EBC@gmail.com> <154771309006279@web41.yandex.ru> <134871310687080@web45.yandex.ru> <2E5005F3-5650-453F-8A0F-92248C0BCE43@gmail.com> <274571310710686@web17.yandex.ru> <448951310736812@web58.yandex.ru> Message-ID: My points: 1. SCL and MCL both have user-extensible stream support, but their stream class hierarchy are using different names from Gray Stream. 2. A Common Lisp implementation which doesn't support any user-extensible streams API cannot be patched to support Gray Stream, but this is not our case. 3. Current trivial-gray-streams basically map Gray Stream support from different packages into the same package (:trivial-gray-stream), but if the project also maps different stream classes names into the same class as defined by Gray Stream, it's still trivial. 4. SCL is commercial implementation, some customers may use old version, so a patch to SCL itself won't be a choice. This also applied to MCL, which many users are using old versions on legacy PowerPC systems. 5. There's no need to change SCL/MCL for every user application, which may not need Gray Streams at all. So, the loadable Gray Streams patch should only be applied when trivial-gray-streams are loaded, and then this means the patch should live with trivial-gray-stream, i.e. being part of it. As you can see, the patch changed some CL standard functions into CLOS generic functions, this may break old Lisp applications on MCL, but won't break new Lisp applications which based on trivial-gray-streams. --binghe ? 2011-7-15?21:33? Anton Vodonosov ??? > > BTW, the main question is not to test the code works (As far as I understand you already tested it in the past). > > Lets decide, if this code should be committed to trivial-gray-streams, or to MCL/SCL. > To me it looks like the latter is more appropriate, because gray streams is a way to extend system > functions like READ-CHAR, CLOSE, etc to work with user-defined streams. > Therefore the extension interface should come with the implementation of READ-CHAR, CLOSE, etc. > > Also, if the code relies on, or needs to modify MCL/SCL internals (is it valid to > redefine COMMON-LISP:OPEN-STREAM-P to be generic function, while in MC it is a usual function), > it is another argument for committing the code to MCL/SCL > > Best regards, > - Anton > > 15.07.2011, 10:33, "Anton Vodonosov" ;: > >> Ok, lets hold it for a while, because I am also bit busy now. >> >> Best regards, >> - Anton >> >> 15.07.2011, 05:14, "Chun Tian (binghe)" ;;: >>> Hi, Anton >>> >>> I'm a little busy these days in other Lisp projects. I still believe the MCL/SCL support code works, I'll prove this in short future. If no others help me on this, I suggest holding this issue for now. >>> >>> Regards, >>> >>> Chun Tian (binghe) >> _______________________________________________ >> trivial-gray-streams-devel mailing list >> trivial-gray-streams-devel at common-lisp.net >> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/trivial-gray-streams-devel