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

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

Re: [Pharo-project] Process Tests and

by Frank Shearar

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

June 13, 2012

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

by Benjamin

On Jun 13, 2012, at 6:23 AM, phil(a)highoctane.be wrote: > Esteban, > > Definitely worth doing!!! > > Install all the stuff I need on new images etc just to the have to > discard them for some reason doesn't makes me reinstall anything > afterwards. > > Tried to work the way of Mariano with the "ConfigurationOfXXXX" but > frankly, let it fall by the wayside. > > Just too many problems with loading packages that do work well together etc. > > And no refactoring out of the box in 1.4 is really lame indeed. As for > Nautilus in 2.0, the regular yellow crosses on red background are > getting on my nerves, especially since I don't know why they do > appear.$ Did you open bug entries ? Send a mail ? Did something ? Ben > > So, yeah: +100000000 > > Philippe > > 2012/6/13 Esteban Lorenzano <estebanlm(a)gmail.com>: >> 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

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

by GÃ¶ran Krampe

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

June 13, 2012

Re: [Pharo-project] Fastest utf-8 encoder contest

by Philippe Marschall

On 06/13/2012 02:59 PM, Igor Stasenko wrote: > On 13 June 2012 10:31, Philippe Marschall > <philippe.marschall(a)netcetera.ch> wrote: >> On 06/13/2012 04:44 AM, Igor Stasenko wrote: >>> Hi, hardcore hackers. >>> please take a look at the code and tell if it can be improved. >>> >>> The AsmJit snippet below transforms an unicode integer value >>> to 1..4-byte sequence of utf-8 >>> >>> then the outer piece of code (which is not yet written) will >>> accumulate the results of this snippet >>> to do a memory-aligned (4byte) writes.. >>> like that, if 4 unicode characters can be encoded into 4 utf-8 bytes >>> (which mostly the case for latin-1 char range), then there will be >>> 4 memory reads (to read four 32-bit unicode values) but only single >>> memory write (to write four 8-bit utf-8 encoded values). >>> >>> The idea is to make utf-8 encoding speed close to memory copying speed :) >> >> In Seaside we use an other trick that Andreas Raab come up with. The >> assumption is that most of the strings are ASCII [1]. We use a CharSet / >> bitmap to quickly scan the string for the index of the first non-ASCII >> character. If we find none we just answer the argument. No copying at all. >> > > Well, in my case i will need copying because i need to null-terminate it, > to represent it as null-terminated string. > This is what cairo library expects as input for rendering text. > And this also means that i can use a single buffer for conversions to > avoid generating garbage, i.e. > i take input string, convert it to utf8 in private buffer, then pass > that buffer as input to external call, > on next call an input can be any other string, but output will be the > same private buffer. > I will be needing to allocate new buffer if incoming string does not > fits into it. I see, different use case. Cheers Philippe

June 13, 2012

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

by Yanni Chiu

On 13/06/12 5:08 AM, Esteban Lorenzano wrote: > > - pre-load OmniBrowser. > - pre-load Spotlight As long as it unloads cleanly, then okay. Would #cleanUpForProduction do the unload?

June 13, 2012