- Pharo-dev - lists.pharo.org

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

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

by petton.nicolas＠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 Guillermo Polito

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... :/ 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 >>>> >>>> >>> >>> >>> >> >> >

June 13, 2012

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

by Levente Uzonyi

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 >>> >> >> >> > >

June 13, 2012

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

by Damien Cassou

On Wed, Jun 13, 2012 at 2:56 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > oc := OrderedCollection new. > ws := oc writeStream. streaming over an OrderedCollection is officially not supported for standard streams (see http://scg.unibe.ch/scgbib?query=Cass09a for details). You can only stream over an Array or String. Or you can use Nile that doesn't have this problem. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 13, 2012

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

by David T. Lewis

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. Dave

June 13, 2012