Hi
While I was optimizing some Seaside code I found out that SocketStream does not understand #next:putAll:startingAt: [1]. It's quite a helpful method that allows one to write a subcollection of a collection to a stream without making a copy. In our case it would allow the codec to directly write to the socket stream. Anyway what I wanted to say is this is fixed in Network-Kernel-pmm.29 ;-) [1] http://code.google.com/p/pharo/issues/detail?id=2292 Cheers Philippe _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Cool!
Soon in the best shop close to you :) Stef On Apr 11, 2010, at 7:03 PM, Philippe Marschall wrote: > Hi > > While I was optimizing some Seaside code I found out that SocketStream > does not understand #next:putAll:startingAt: [1]. It's quite a helpful > method that allows one to write a subcollection of a collection to a > stream without making a copy. In our case it would allow the codec to > directly write to the socket stream. > > Anyway what I wanted to say is this is fixed in Network-Kernel-pmm.29 ;-) > > [1] http://code.google.com/p/pharo/issues/detail?id=2292 > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Philippe Marschall-2-3
On Sun, 11 Apr 2010, Philippe Marschall wrote:
> Hi > > While I was optimizing some Seaside code I found out that SocketStream > does not understand #next:putAll:startingAt: [1]. It's quite a helpful > method that allows one to write a subcollection of a collection to a > stream without making a copy. In our case it would allow the codec to > directly write to the socket stream. > > Anyway what I wanted to say is this is fixed in Network-Kernel-pmm.29 ;-) > > [1] http://code.google.com/p/pharo/issues/detail?id=2292 FYI: http://code.google.com/p/pharo/issues/detail?id=2244 Levente > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
thanks for the reminder
Philippe I just integrated your fixes. Could you have a look at the entry pointed by levente? Stef On Apr 11, 2010, at 9:46 PM, Levente Uzonyi wrote: > On Sun, 11 Apr 2010, Philippe Marschall wrote: > >> Hi >> >> While I was optimizing some Seaside code I found out that SocketStream >> does not understand #next:putAll:startingAt: [1]. It's quite a helpful >> method that allows one to write a subcollection of a collection to a >> stream without making a copy. In our case it would allow the codec to >> directly write to the socket stream. >> >> Anyway what I wanted to say is this is fixed in Network-Kernel-pmm.29 ;-) >> >> [1] http://code.google.com/p/pharo/issues/detail?id=2292 > > FYI: http://code.google.com/p/pharo/issues/detail?id=2244 > > > Levente > >> >> Cheers >> Philippe >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Levente Uzonyi-2
On 11.04.2010 21:46, Levente Uzonyi wrote:
> On Sun, 11 Apr 2010, Philippe Marschall wrote: > >> Hi >> >> While I was optimizing some Seaside code I found out that SocketStream >> does not understand #next:putAll:startingAt: [1]. It's quite a helpful >> method that allows one to write a subcollection of a collection to a >> stream without making a copy. In our case it would allow the codec to >> directly write to the socket stream. >> >> Anyway what I wanted to say is this is fixed in Network-Kernel-pmm.29 ;-) >> >> [1] http://code.google.com/p/pharo/issues/detail?id=2292 > > FYI: http://code.google.com/p/pharo/issues/detail?id=2244 Oops, sorry. The merged code is a bit different, it's oriented more towards the current #nextPutAll: - it answers self like #nextPutAll: and not the collection passed in. ANSI says it's unspecified and current implementations are not conclusive, most answer the collection but not all. That probably means we should change #nextPutAll: as well. - it explicitly checks for n = 0 as a guarding clause. That's certainly discussable, I found algorithms easier to write when I don't have to check for n = 0 at the send site. - it had an off by one error - like #nextPutAll: it does type conversion based on the mode. To sum up: - #nextPutAll: and #next:putAll:startingAt: should probably be changed to answer the collection and fix other implementations. - if the type conversion is needed (I believe so) then SocketStream should do it - the n = 0 guarding clause is discussable - IMO consistency with #nextPutAll: is important Cheers Philippe _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On Apr 12, 2010, at 7:53 PM, Philippe Marschall wrote: > On 11.04.2010 21:46, Levente Uzonyi wrote: >> On Sun, 11 Apr 2010, Philippe Marschall wrote: >> >>> Hi >>> >>> While I was optimizing some Seaside code I found out that SocketStream >>> does not understand #next:putAll:startingAt: [1]. It's quite a helpful >>> method that allows one to write a subcollection of a collection to a >>> stream without making a copy. In our case it would allow the codec to >>> directly write to the socket stream. >>> >>> Anyway what I wanted to say is this is fixed in Network-Kernel-pmm.29 ;-) >>> >>> [1] http://code.google.com/p/pharo/issues/detail?id=2292 >> >> FYI: http://code.google.com/p/pharo/issues/detail?id=2244 > > Oops, sorry. > > The merged code is a bit different, it's oriented more towards the > current #nextPutAll: > - it answers self like #nextPutAll: and not the collection passed > in. ANSI says it's unspecified and current implementations are not > conclusive, most answer the collection but not all. That probably means > we should change #nextPutAll: as well. > - it explicitly checks for n = 0 as a guarding clause. That's certainly > discussable, I found algorithms easier to write when I don't have to > check for n = 0 at the send site. > - it had an off by one error > - like #nextPutAll: it does type conversion based on the mode. > > To sum up: > - #nextPutAll: and #next:putAll:startingAt: should probably be changed > to answer the collection and fix other implementations. nicolas did the inverse in squeak > - if the type conversion is needed (I believe so) then SocketStream > should do it > - the n = 0 guarding clause is discussable > - IMO consistency with #nextPutAll: is important do you have some code? Because it seems that you have more knowledge than me on that :) Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |