- Pharo-dev - lists.pharo.org

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

by Igor Stasenko

On 14 June 2012 08:33, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Tx > > now there is a difference between adjustments and fully new API and I would have preferred adjustments. > > Stef IMO, Xtreams design is simply superior. But i agree, we cannot throw existing streams out.. too much things tied to them, and rely on using stream protocols. :( -- Best regards, Igor Stasenko.

June 14, 2012

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

by StÃ©phane Ducasse

Tx now there is a difference between adjustments and fully new API and I would have preferred adjustments. Stef On Jun 14, 2012, at 12:11 AM, Frank Shearar wrote: > On 13 June 2012 20:25, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: >> I would have really prefer that Xtreams provide a compatible API. >> Because changing API means also rewrite documentationâ¦. > > If I recall correctly, Michael & Martin said that it was impossible to > provide a compatible API because the ANSI Stream protocol was > fundamentally broken in a few key ways. I forget the details though, > sadly. > >> Nicolas else did you get Xtream working well in Pharo? > > It should work just fine. As I recall there wasn't much adjustment > necessary for Squeak (but of course Nicolas would know better than > anyone!). > > frank > >> 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 14, 2012

[Pharo-project] Pharo-1.4-Tests Â» 32,win - Build # 60 - Failure!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

June 14, 2012

Re: [Pharo-project] Process Tests and

by Eliot Miranda

On Wed, Jun 13, 2012 at 7:35 AM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > On 2 June 2012 09:28, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > > Hi Sean: > > > > On 02 Jun 2012, at 05:07, Sean P. DeNigris wrote: > > > >> During the process, I noticed that the Blue Book specifies that #fork > >> returns the block itself (pg. 252), while in Pharo it returns the > process > >> (see #testFork in the slice). Should our implementation be changed to > match > >> the Blue Book? > > > > Why would it be desirable to have the block? > > How would you obtain the process object after your change? > > > > Having the process directly is useful to do fork/join style operations. > > How do you #join Processes? I can't see anything in Process' protocol > for doing so. so what am I missing? > Nothing. Theres no support for join. You have to roll your own. > > frank > > > Best regards > > Stefan > > > > -- > > Stefan Marr > > Software Languages Lab > > Vrije Universiteit Brussel > > Pleinlaan 2 / B-1050 Brussels / Belgium > > http://soft.vub.ac.be/~smarr > > Phone: +32 2 629 2974 > > Fax: +32 2 629 3525 > > > > > > -- best, Eliot

June 13, 2012

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

by Frank Shearar

On 13 June 2012 20:25, StÃ©phane Ducasse <Stephane.Ducasse(a)inria.fr> wrote: > I would have really prefer that Xtreams provide a compatible API. > Because changing API means also rewrite documentationâ¦. If I recall correctly, Michael & Martin said that it was impossible to provide a compatible API because the ANSI Stream protocol was fundamentally broken in a few key ways. I forget the details though, sadly. > Nicolas else did you get Xtream working well in Pharo? It should work just fine. As I recall there wasn't much adjustment necessary for Squeak (but of course Nicolas would know better than anyone!). frank > 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] [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