June 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Vm-dev] Cog issue? Re: StandardFileStream size limit?

by Eliot Miranda

On Wed, Jun 13, 2012 at 7:40 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Wed, Jun 13, 2012 at 04:08:14PM +0200, G?ran Krampe wrote: > > > > Hey! > > > > Ok, so the plot thickens: > > > > If I run this in a "oneclick 1.4" I will get a file write error on 2Gb: > > > > | f b | > > f := StandardFileStream newFileNamed: 'test'. > > b := ByteArray new: 1024*1024*100. "100Mb" > > [30 timesRepeat: [f nextPutAll: b]] ensure: [f close] "3Gb" > > > > > > ...but it worked fine using a self built "standard" VM from squeakvm.org > > (4.4.7.2357)! Same image btw. > > > > Now, does it work with the bleeding edge Cog? Tried r2556 and nope, same > > problem. > > > > So I "guess" it is a Cog thing? I haven't tried building Cog from source. > > > > regards, G?ran > > Background on large file support, see especially Bert's summary: > > > http://forum.world.st/Re-squeak-dev-filesize-reporting-0-for-very-large-fil… > http://bugs.squeak.org/view.php?id=7522 > http://www.suse.de/~aj/linux_lfs.html > > I'm not sure if the Cog VMs are being compiled with the the LFS option, > although > I expect that if you compile it yourself with the build options that Bert > explains, > then it should start working. > I just committed the necessary changes for my branch. Will rebuild soon. GÃ¶ran, if you're in a hurry build your own? You'd need to be in http://www.squeakvm.org/svn/squeak/branches/Cog/unixbuild/bld and run ./mvm. -- best, Eliot

June 13, 2012

Re: [Pharo-project] WriteStream, nextPutAll:, OrderedCollections

by Denis Kudriashov

Hi I try it on Pharo1.4 - all tests green. http://www.squeaksource.com/Xtreams.html page contains gofer scripts. Without last ffi packages (for VW I thing) all are loadable and work good. 2012/6/13 StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> > I would have really prefer that Xtreams provide a compatible API. > Because changing API means also rewrite documentationâ¦. > > Nicolas else did you get Xtream working well in Pharo? > Because we will nearly killed all the old FileDirectory code. So stream > would be good candidate to clean too. > Stef > > > > If it's about switching to a clean library maximizing the power of > > composition use Xtreams. > > If it's about maximizing compatibility, use Nile. The composition in > > Nile is done via Traits, this is interesting but spectrum is quite > > narrow. Nile also introduces lazy streams and filters, but this is > > less systematic than Xtreams, because the main goal was to replace > > legacy Stream, innovation being secondary. > > > > Of course, in the first case, you break a lot of clients because > > design decision is to change the whole API and force a rewrite. > > So you must have a long transition phase maintaining legacy Streams > > > > And in second case, you can eliminate the legacy streams more rapidly > > and just replace them with Nile, but you still carry some cruft, > > compatibility oblige... > > > > Not an easy choice, but you can guess my opinion ;) > > > > Nicolas > > > > 2012/6/13 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> And why no Xtreams? > >> > >> 2012/6/13 <petton.nicolas(a)gmail.com> > >> > >>> Guillermo Polito <guillermopolito(a)gmail.com> writes: > >>> > >>>> Ok, just was expecting (very very deeply) not having to modify too > >>>> much in Glorp :). Anyway, I'll see what can I do in this front. > >>>> > >>>> Now Damien, if streaming is only intended for arrays and strings, I'd > >>>> expect the expression 'OrderedCollection new writeStream' to raise an > >>>> error... :/ > >>> > >>> Indeed. Also, just for my information, why aren't we using Nile? > >>> > >>> Nico > >>> > >>>> > >>>> On Wed, Jun 13, 2012 at 5:29 PM, Levente Uzonyi <leves(a)elte.hu> > wrote: > >>>> > >>>> On Wed, 13 Jun 2012, Guillermo Polito wrote: > >>>> > >>>> soo, what do I do? :D > >>>> > >>>> > >>>> > >>>> Streaming into an OrderedCollection is unnecessary, because > >>>> OrderedCollection is already a stream-like object. If I were > >>>> implementing Smalltalk now, I would probably add the stream > >>>> protocol to it (#nextPut:, #nextPutAll:, etc). > >>>> A simple fix to your problem is to replace the line > >>>> > >>>> grownCollection := collection class new: newSize. > >>>> > >>>> with > >>>> > >>>> grownCollection := collection class ofSize: newSize. > >>>> > >>>> in WriteStream >> #growTo: (note that I didn't check current Pharo > >>>> code, so this might be different there). > >>>> > >>>> > >>>> Levente > >>>> > >>>> > >>>> > >>>> > >>>> On 6/13/12, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >>>> > >>>> yup I know that :D > >>>> And I provided a fix on e year ago, that got lost in a big > >>>> refactoring... > >>>> - I added an explicit #streamSpecies on the Collection > >>>> classes. > >>>> - By default it returns the same class > >>>> - on Set / OrderedCollection / Symbol it returns the > >>>> mutable types > >>>> (LinkedList as well I think) > >>>> - overwrote #streamContents: to convert from the > >>>> #streamSpecies type back to > >>>> the original class > >>>> > >>>> > >>>> > >>>> On 2012-06-13, at 14:56, Guillermo Polito wrote: > >>>> > >>>> Hi guys! > >>>> > >>>> I'm chasing a bug that appeared in glorp under pharo > >>>> 1.4. Now, the > >>>> bug is due to some behavior changed in > >>>> OrderedCollection I think. Look > >>>> at this piece of code: > >>>> > >>>> > >>>> oc := OrderedCollection new. > >>>> ws := oc writeStream. > >>>> > >>>> "this explodes" > >>>> ws nextPutAll: (OrderedCollection with: 1 with: 2 > >>>> with: 3). > >>>> > >>>> "this works" > >>>> ws nextPutAll: {1.2.3} > >>>> > >>>> > >>>> And I'm puzzled, why should one work and the other not > >>>> from the pov of the > >>>> user? > >>>> And how should I replace that behavior if it's my bug? > >>>> > >>>> putting an asArray for each nextPutAll: does not look > >>>> good for me... :S > >>>> > >>>> Tx, > >>>> Guille > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> -- > >>> Nicolas Petton > >>> http://nicolas-petton.fr > >>> > >> > > > > >

June 13, 2012

Re: [Pharo-project] WriteStream, nextPutAll:, OrderedCollections

by StÃ©phane Ducasse

I would have really prefer that Xtreams provide a compatible API. Because changing API means also rewrite documentationâ¦. Nicolas else did you get Xtream working well in Pharo? Because we will nearly killed all the old FileDirectory code. So stream would be good candidate to clean too. Stef > If it's about switching to a clean library maximizing the power of > composition use Xtreams. > If it's about maximizing compatibility, use Nile. The composition in > Nile is done via Traits, this is interesting but spectrum is quite > narrow. Nile also introduces lazy streams and filters, but this is > less systematic than Xtreams, because the main goal was to replace > legacy Stream, innovation being secondary. > > Of course, in the first case, you break a lot of clients because > design decision is to change the whole API and force a rewrite. > So you must have a long transition phase maintaining legacy Streams > > And in second case, you can eliminate the legacy streams more rapidly > and just replace them with Nile, but you still carry some cruft, > compatibility oblige... > > Not an easy choice, but you can guess my opinion ;) > > Nicolas > > 2012/6/13 Denis Kudriashov <dionisiydk(a)gmail.com>: >> And why no Xtreams? >> >> 2012/6/13 <petton.nicolas(a)gmail.com> >> >>> Guillermo Polito <guillermopolito(a)gmail.com> writes: >>> >>>> Ok, just was expecting (very very deeply) not having to modify too >>>> much in Glorp :). Anyway, I'll see what can I do in this front. >>>> >>>> Now Damien, if streaming is only intended for arrays and strings, I'd >>>> expect the expression 'OrderedCollection new writeStream' to raise an >>>> error... :/ >>> >>> Indeed. Also, just for my information, why aren't we using Nile? >>> >>> Nico >>> >>>> >>>> On Wed, Jun 13, 2012 at 5:29 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >>>> >>>> On Wed, 13 Jun 2012, Guillermo Polito wrote: >>>> >>>> soo, what do I do? :D >>>> >>>> >>>> >>>> Streaming into an OrderedCollection is unnecessary, because >>>> OrderedCollection is already a stream-like object. If I were >>>> implementing Smalltalk now, I would probably add the stream >>>> protocol to it (#nextPut:, #nextPutAll:, etc). >>>> A simple fix to your problem is to replace the line >>>> >>>> grownCollection := collection class new: newSize. >>>> >>>> with >>>> >>>> grownCollection := collection class ofSize: newSize. >>>> >>>> in WriteStream >> #growTo: (note that I didn't check current Pharo >>>> code, so this might be different there). >>>> >>>> >>>> Levente >>>> >>>> >>>> >>>> >>>> On 6/13/12, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>>> >>>> yup I know that :D >>>> And I provided a fix on e year ago, that got lost in a big >>>> refactoring... >>>> - I added an explicit #streamSpecies on the Collection >>>> classes. >>>> - By default it returns the same class >>>> - on Set / OrderedCollection / Symbol it returns the >>>> mutable types >>>> (LinkedList as well I think) >>>> - overwrote #streamContents: to convert from the >>>> #streamSpecies type back to >>>> the original class >>>> >>>> >>>> >>>> On 2012-06-13, at 14:56, Guillermo Polito wrote: >>>> >>>> Hi guys! >>>> >>>> I'm chasing a bug that appeared in glorp under pharo >>>> 1.4. Now, the >>>> bug is due to some behavior changed in >>>> OrderedCollection I think. Look >>>> at this piece of code: >>>> >>>> >>>> oc := OrderedCollection new. >>>> ws := oc writeStream. >>>> >>>> "this explodes" >>>> ws nextPutAll: (OrderedCollection with: 1 with: 2 >>>> with: 3). >>>> >>>> "this works" >>>> ws nextPutAll: {1.2.3} >>>> >>>> >>>> And I'm puzzled, why should one work and the other not >>>> from the pov of the >>>> user? >>>> And how should I replace that behavior if it's my bug? >>>> >>>> putting an asArray for each nextPutAll: does not look >>>> good for me... :S >>>> >>>> Tx, >>>> Guille >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> Nicolas Petton >>> http://nicolas-petton.fr >>> >> >

June 13, 2012

Re: [Pharo-project] StandardFileStream size limit?

by Eliot Miranda

On Wed, Jun 13, 2012 at 12:35 AM, GÃ¶ran Krampe <goran(a)krampe.se> wrote: > Hey all! > > I have just added large file (chunkwise upload and download) support to > Kom/Networking/Iliad in Pharo 1.4 and while testing it I tried uploading a > 2.9Gb file. > > I haven't looked at the exact error message, and I haven't tried writing a > trivial test - but the "half written" file on disk is almost EXACTLY 2Gb > (2147483647) so I am wondering - do we still have a 2Gb file size limit? > I think so. Still need to add the relevant define (LARGEFILE_SOURCE or some such) to the linux build to enable 64-bit file support. > > This is "one click 1.4" on Ubuntu 64 with ext4. > > regards, GÃ¶ran > -- best, Eliot

June 13, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by phil＠highoctane.be

Can't help remember something old... Clipper Summer '87. The name was sticking for a long while. http://en.wikipedia.org/wiki/Clipper_(programming_language) You'll see the Seasonal Versions, which is quite a nice idea in fact as it allows interesting themeing to take place. There was a VM and blocks... A mix of a compiler and an embarked interpreter. Wrote a ton of apps for businesses in order to pay for my university fees. Worked well. :-) Philippe. 2012/6/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Call it SummerRain :). > > Yes this is a good idea. > > What we should do also is to push and validate metacello Configs. We should really move on such topic. > > > Stef > > On Jun 13, 2012, at 11:08 AM, Esteban Lorenzano wrote: > >> Hi, >> >> I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number). >> I've been monitoring the list and I think there are some things to improve, so I'm planning to add this things to new one click: >> >> - pre-load OmniBrowser. >> Why I'm suggesting this? Because nobody seems to notice that OB is actually working on 1.4 and everybody complains that "you cannot have refactors, blabla", which is just not true, but is causing a lot of bad feeling around what is a great release (yes, I'm making some constructive criticism about the list attitude, but also about our/mine communicational capabilities). >> Original idea was to allow people to choose OB or Nautilus, since the last one will be the browser for Pharo in the future, but truth is that Nautilus is still a "technology preview"... and it will be there for all those like me, who want to use it. >> Finally, most important issue is that newcomers expect to have a full environment working out of the box, and they don'y know how to use the Configuration Browser. >> >> - pre-load Spotlight >> Yeah, another small tool who can make your life easy. >> Why? just because I'm tired of seeing all of you typing class names at workspace and press cmd+b later... or using some more uncomfortable ways to reach your code. >> If you still prefer those ways, is up to you ;) >> >> So far, this and the bugfixes we already made (and some more)... >> >> What do you think? >> >> Esteban > > -- Philippe Back Dramatic Performance Improvments Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium

June 13, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by StÃ©phane Ducasse

Call it SummerRain :). Yes this is a good idea. What we should do also is to push and validate metacello Configs. We should really move on such topic. Stef On Jun 13, 2012, at 11:08 AM, Esteban Lorenzano wrote: > Hi, > > I started thinking on next release of Pharo 1.4 (which will be code named "summer", not an ugly number). > I've been monitoring the list and I think there are some things to improve, so I'm planning to add this things to new one click: > > - pre-load OmniBrowser. > Why I'm suggesting this? Because nobody seems to notice that OB is actually working on 1.4 and everybody complains that "you cannot have refactors, blabla", which is just not true, but is causing a lot of bad feeling around what is a great release (yes, I'm making some constructive criticism about the list attitude, but also about our/mine communicational capabilities). > Original idea was to allow people to choose OB or Nautilus, since the last one will be the browser for Pharo in the future, but truth is that Nautilus is still a "technology preview"... and it will be there for all those like me, who want to use it. > Finally, most important issue is that newcomers expect to have a full environment working out of the box, and they don'y know how to use the Configuration Browser. > > - pre-load Spotlight > Yeah, another small tool who can make your life easy. > Why? just because I'm tired of seeing all of you typing class names at workspace and press cmd+b later... or using some more uncomfortable ways to reach your code. > If you still prefer those ways, is up to you ;) > > So far, this and the bugfixes we already made (and some more)... > > What do you think? > > Esteban

June 13, 2012

Re: [Pharo-project] WriteStream, nextPutAll:, OrderedCollections

by Nicolas Cellier

By the way, OrderedCollection new writing write: ({1. 2. 3.} as: OrderedCollection); conclusion 2012/6/13 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > If it's about switching to a clean library maximizing the power of > composition use Xtreams. > If it's about maximizing compatibility, use Nile. The composition in > Nile is done via Traits, this is interesting but spectrum is quite > narrow. Nile also introduces lazy streams and filters, but this is > less systematic than Xtreams, because the main goal was to replace > legacy Stream, innovation being secondary. > > Of course, in the first case, you break a lot of clients because > design decision is to change the whole API and force a rewrite. > So you must have a long transition phase maintaining legacy Streams > > And in second case, you can eliminate the legacy streams more rapidly > and just replace them with Nile, but you still carry some cruft, > compatibility oblige... > > Not an easy choice, but you can guess my opinion ;) > > Nicolas > > 2012/6/13 Denis Kudriashov <dionisiydk(a)gmail.com>: >> And why no Xtreams? >> >> 2012/6/13 <petton.nicolas(a)gmail.com> >> >>> Guillermo Polito <guillermopolito(a)gmail.com> writes: >>> >>> > Ok, just was expecting (very very deeply) not having to modify too >>> > much in Glorp :). Anyway, I'll see what can I do in this front. >>> > >>> > Now Damien, if streaming is only intended for arrays and strings, I'd >>> > expect the expression 'OrderedCollection new writeStream' to raise an >>> > error... :/ >>> >>> Indeed. Also, just for my information, why aren't we using Nile? >>> >>> Nico >>> >>> > >>> > On Wed, Jun 13, 2012 at 5:29 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >>> > >>> > Â Â On Wed, 13 Jun 2012, Guillermo Polito wrote: >>> > >>> > Â Â Â Â soo, what do I do? :D >>> > >>> > >>> > >>> > Â Â Streaming into an OrderedCollection is unnecessary, because >>> > Â Â OrderedCollection is already a stream-like object. If I were >>> > Â Â implementing Smalltalk now, I would probably add the stream >>> > Â Â protocol to it (#nextPut:, #nextPutAll:, etc). >>> > Â Â A simple fix to your problem is to replace the line >>> > >>> > Â Â Â Â Â Â grownCollection := collection class new: newSize. >>> > >>> > Â Â with >>> > >>> > Â Â Â Â Â Â grownCollection := collection class ofSize: newSize. >>> > >>> > Â Â in WriteStream >> #growTo: (note that I didn't check current Pharo >>> > Â Â code, so this might be different there). >>> > >>> > >>> > Â Â Levente >>> > >>> > >>> > >>> > >>> > Â Â Â Â On 6/13/12, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> > >>> > Â Â Â Â yup I know that :D >>> > Â Â Â Â Â Â And I provided a fix on e year ago, that got lost in a big >>> > Â Â Â Â Â Â refactoring... >>> > Â Â Â Â Â Â - I added an explicit #streamSpecies on the Collection >>> > Â Â Â Â Â Â classes. >>> > Â Â Â Â Â Â - By default it returns the same class >>> > Â Â Â Â Â Â - on Set / OrderedCollection / Symbol it returns the >>> > Â Â Â Â Â Â mutable types >>> > Â Â Â Â Â Â (LinkedList as well I think) >>> > Â Â Â Â Â Â - overwrote #streamContents: to convert from the >>> > Â Â Â Â Â Â #streamSpecies type back to >>> > Â Â Â Â Â Â the original class >>> > >>> > >>> > >>> > Â Â Â Â Â Â On 2012-06-13, at 14:56, Guillermo Polito wrote: >>> > >>> > Â Â Â Â Â Â Â Â Â Â Â Â Hi guys! >>> > >>> > Â Â Â Â Â Â Â Â I'm chasing a bug that appeared in glorp under pharo >>> > Â Â Â Â Â Â Â Â 1.4. Â Now, the >>> > Â Â Â Â Â Â Â Â bug is due to some behavior changed in >>> > Â Â Â Â Â Â Â Â OrderedCollection I think. Look >>> > Â Â Â Â Â Â Â Â at this piece of code: >>> > >>> > >>> > Â Â Â Â Â Â Â Â oc := OrderedCollection new. >>> > Â Â Â Â Â Â Â Â ws := oc writeStream. >>> > >>> > Â Â Â Â Â Â Â Â "this explodes" >>> > Â Â Â Â Â Â Â Â ws nextPutAll: (OrderedCollection with: 1 with: 2 >>> > Â Â Â Â Â Â Â Â with: 3). >>> > >>> > Â Â Â Â Â Â Â Â "this works" >>> > Â Â Â Â Â Â Â Â ws nextPutAll: {1.2.3} >>> > >>> > >>> > Â Â Â Â Â Â Â Â And I'm puzzled, why should one work and the other not >>> > Â Â Â Â Â Â Â Â from the pov of the >>> > Â Â Â Â Â Â Â Â user? >>> > Â Â Â Â Â Â Â Â And how should I replace that behavior if it's my bug? >>> > >>> > Â Â Â Â Â Â Â Â putting an asArray for each nextPutAll: does not look >>> > Â Â Â Â Â Â Â Â good for me... :S >>> > >>> > Â Â Â Â Â Â Â Â Tx, >>> > Â Â Â Â Â Â Â Â Guille >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> >>> -- >>> Nicolas Petton >>> http://nicolas-petton.fr >>> >>

June 13, 2012

Re: [Pharo-project] WriteStream, nextPutAll:, OrderedCollections

by Nicolas Cellier

If it's about switching to a clean library maximizing the power of composition use Xtreams. If it's about maximizing compatibility, use Nile. The composition in Nile is done via Traits, this is interesting but spectrum is quite narrow. Nile also introduces lazy streams and filters, but this is less systematic than Xtreams, because the main goal was to replace legacy Stream, innovation being secondary. Of course, in the first case, you break a lot of clients because design decision is to change the whole API and force a rewrite. So you must have a long transition phase maintaining legacy Streams And in second case, you can eliminate the legacy streams more rapidly and just replace them with Nile, but you still carry some cruft, compatibility oblige... Not an easy choice, but you can guess my opinion ;) Nicolas 2012/6/13 Denis Kudriashov <dionisiydk(a)gmail.com>: > And why no Xtreams? > > 2012/6/13 <petton.nicolas(a)gmail.com> > >> Guillermo Polito <guillermopolito(a)gmail.com> writes: >> >> > Ok, just was expecting (very very deeply) not having to modify too >> > much in Glorp :). Anyway, I'll see what can I do in this front. >> > >> > Now Damien, if streaming is only intended for arrays and strings, I'd >> > expect the expression 'OrderedCollection new writeStream' to raise an >> > error... :/ >> >> Indeed. Also, just for my information, why aren't we using Nile? >> >> Nico >> >> > >> > On Wed, Jun 13, 2012 at 5:29 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >> > >> > Â Â On Wed, 13 Jun 2012, Guillermo Polito wrote: >> > >> > Â Â Â Â soo, what do I do? :D >> > >> > >> > >> > Â Â Streaming into an OrderedCollection is unnecessary, because >> > Â Â OrderedCollection is already a stream-like object. If I were >> > Â Â implementing Smalltalk now, I would probably add the stream >> > Â Â protocol to it (#nextPut:, #nextPutAll:, etc). >> > Â Â A simple fix to your problem is to replace the line >> > >> > Â Â Â Â Â Â grownCollection := collection class new: newSize. >> > >> > Â Â with >> > >> > Â Â Â Â Â Â grownCollection := collection class ofSize: newSize. >> > >> > Â Â in WriteStream >> #growTo: (note that I didn't check current Pharo >> > Â Â code, so this might be different there). >> > >> > >> > Â Â Levente >> > >> > >> > >> > >> > Â Â Â Â On 6/13/12, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> > >> > Â Â Â Â yup I know that :D >> > Â Â Â Â Â Â And I provided a fix on e year ago, that got lost in a big >> > Â Â Â Â Â Â refactoring... >> > Â Â Â Â Â Â - I added an explicit #streamSpecies on the Collection >> > Â Â Â Â Â Â classes. >> > Â Â Â Â Â Â - By default it returns the same class >> > Â Â Â Â Â Â - on Set / OrderedCollection / Symbol it returns the >> > Â Â Â Â Â Â mutable types >> > Â Â Â Â Â Â (LinkedList as well I think) >> > Â Â Â Â Â Â - overwrote #streamContents: to convert from the >> > Â Â Â Â Â Â #streamSpecies type back to >> > Â Â Â Â Â Â the original class >> > >> > >> > >> > Â Â Â Â Â Â On 2012-06-13, at 14:56, Guillermo Polito wrote: >> > >> > Â Â Â Â Â Â Â Â Â Â Â Â Hi guys! >> > >> > Â Â Â Â Â Â Â Â I'm chasing a bug that appeared in glorp under pharo >> > Â Â Â Â Â Â Â Â 1.4. Â Now, the >> > Â Â Â Â Â Â Â Â bug is due to some behavior changed in >> > Â Â Â Â Â Â Â Â OrderedCollection I think. Look >> > Â Â Â Â Â Â Â Â at this piece of code: >> > >> > >> > Â Â Â Â Â Â Â Â oc := OrderedCollection new. >> > Â Â Â Â Â Â Â Â ws := oc writeStream. >> > >> > Â Â Â Â Â Â Â Â "this explodes" >> > Â Â Â Â Â Â Â Â ws nextPutAll: (OrderedCollection with: 1 with: 2 >> > Â Â Â Â Â Â Â Â with: 3). >> > >> > Â Â Â Â Â Â Â Â "this works" >> > Â Â Â Â Â Â Â Â ws nextPutAll: {1.2.3} >> > >> > >> > Â Â Â Â Â Â Â Â And I'm puzzled, why should one work and the other not >> > Â Â Â Â Â Â Â Â from the pov of the >> > Â Â Â Â Â Â Â Â user? >> > Â Â Â Â Â Â Â Â And how should I replace that behavior if it's my bug? >> > >> > Â Â Â Â Â Â Â Â putting an asArray for each nextPutAll: does not look >> > Â Â Â Â Â Â Â Â good for me... :S >> > >> > Â Â Â Â Â Â Â Â Tx, >> > Â Â Â Â Â Â Â Â Guille >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> -- >> Nicolas Petton >> http://nicolas-petton.fr >> >

June 13, 2012

Re: [Pharo-project] DBXTalk & seaside / success in Pier one-click / my 1.4 woes follow-up

by StÃ©phane Ducasse

Let us know how we can help you. Stef On Jun 13, 2012, at 1:52 AM, Cameron Sanders wrote: > Nick & Yanni, > > Starting with a clean Pharo 1.4-one-click, running on a Mac, and loading as listed below (see botton of page), does not deliver the desired results. A trivial Magritte described object, rendered (via #call:) "...asComponent addValidatedForm; yourself)" displays only the buttons, and no content editors. It silently fails. > > My test is the most trivial test of the Person tutorial for Magritte, grab my partial version from > MCHttpRepository > location: 'http://www.debrispublishing.com/camshared' > user: '' > password: '' > > and package is 'Cam'. > See the class method of the Manager to register the app; then open a browser on localhost:8080/cam and when one adds a person, there is nothing but buttons. > > Perhaps the pattern of use is deprecated? > CamPersonManager>>add > | p | > p := self call: (CamPerson new asComponent addValidatedForm ; yourself). > p ifNotNil: [ self persons add: p] > > This same trivial sample code does work in one Pier image I was using. But I was trying really hard to move to a 1.4 image, for the numerous small improvements and fixes; and as Yanni suggested, to be positioned for future support. > > If anyone has seaside/Magritte working in 1.4 would you please share with me your exact loading scripts (in proper sequence), or a snapshot of the minimal image (without any extras, of course)? In the meantime I will try a 1.3 build ... again. > > I have put a lot of hours in trying to get a 1.4 build that works -- and a few failed 1.3 builds. Everyone else seems to do this in stride. But apparently, I am doing something wrong... dumb... idiotic... and my co-workers are starting to doubt me & my choice of platforms. Any help is most appreciated. > > Thanks in advance, > Cam > PS: what I loaded and how -- using Pier config to get seaside & magritte combos that work together (with regard to #description, etc.). > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfPier3'; > load. > (Smalltalk at: #ConfigurationOfPier3) load. > > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfPier3AddOns'; > load. > > (Smalltalk at: #ConfigurationOfPier3AddOns) load. > > "Error about ImageSegment not being available -- used by #serialize: which is used by #snapshot -- but not an issue for me right now, so Proceed" > > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfFuel'; > load. > ((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') > load. >

June 13, 2012

Re: [Pharo-project] WriteStream, nextPutAll:, OrderedCollections

by Denis Kudriashov

And why no Xtreams? 2012/6/13 <petton.nicolas(a)gmail.com> > Guillermo Polito <guillermopolito(a)gmail.com> writes: > > > Ok, just was expecting (very very deeply) not having to modify too > > much in Glorp :). Anyway, I'll see what can I do in this front. > > > > Now Damien, if streaming is only intended for arrays and strings, I'd > > expect the expression 'OrderedCollection new writeStream' to raise an > > error... :/ > > Indeed. Also, just for my information, why aren't we using Nile? > > Nico > > > > > On Wed, Jun 13, 2012 at 5:29 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > > > > On Wed, 13 Jun 2012, Guillermo Polito wrote: > > > > soo, what do I do? :D > > > > > > > > Streaming into an OrderedCollection is unnecessary, because > > OrderedCollection is already a stream-like object. If I were > > implementing Smalltalk now, I would probably add the stream > > protocol to it (#nextPut:, #nextPutAll:, etc). > > A simple fix to your problem is to replace the line > > > > grownCollection := collection class new: newSize. > > > > with > > > > grownCollection := collection class ofSize: newSize. > > > > in WriteStream >> #growTo: (note that I didn't check current Pharo > > code, so this might be different there). > > > > > > Levente > > > > > > > > > > On 6/13/12, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > > yup I know that :D > > And I provided a fix on e year ago, that got lost in a big > > refactoring... > > - I added an explicit #streamSpecies on the Collection > > classes. > > - By default it returns the same class > > - on Set / OrderedCollection / Symbol it returns the > > mutable types > > (LinkedList as well I think) > > - overwrote #streamContents: to convert from the > > #streamSpecies type back to > > the original class > > > > > > > > On 2012-06-13, at 14:56, Guillermo Polito wrote: > > > > Hi guys! > > > > I'm chasing a bug that appeared in glorp under pharo > > 1.4. Now, the > > bug is due to some behavior changed in > > OrderedCollection I think. Look > > at this piece of code: > > > > > > oc := OrderedCollection new. > > ws := oc writeStream. > > > > "this explodes" > > ws nextPutAll: (OrderedCollection with: 1 with: 2 > > with: 3). > > > > "this works" > > ws nextPutAll: {1.2.3} > > > > > > And I'm puzzled, why should one work and the other not > > from the pov of the > > user? > > And how should I replace that behavior if it's my bug? > > > > putting an asArray for each nextPutAll: does not look > > good for me... :S > > > > Tx, > > Guille > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Nicolas Petton > http://nicolas-petton.fr > >

June 13, 2012