- Pharo-dev - lists.pharo.org

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

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

by Guillermo Polito

soo, what do I do? :D 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] Look and font competition

by Igor Stasenko

On 13 June 2012 14:51, camille teruel <camille.teruel(a)gmail.com> wrote: > EFL stands for Enlightenment Foundation Librairies > It is a set of C librairies that are used for the E17 window manager (a > famous vaporware). > E17 is still in alpha (since a very long time but it is usable, give it a > try if you have a linux distro somewhere), because they're currently working > on EFLs stabilisation.Â These libraries have a pretty good reputation. > That's the main website:Â http://www.enlightenment.org/ > The canva library is called Evas. > ahh.. Enlightenment.. it was vaporware since the first time i saw it, back in 98 (i think) :) > > > 2012/6/13 Igor Stasenko <siguctua(a)gmail.com> >> >> On 13 June 2012 10:52, camille teruel <camille.teruel(a)gmail.com> wrote: >> > 2012/6/12 Igor Stasenko <siguctua(a)gmail.com> >> >> >> >> On 12 June 2012 23:28, Helene Bilbo >> >> <thereluctantprogrammer(a)fastmail.fm> >> >> wrote: >> >> > The subtle texture is more like overlaying the existing elements with >> >> > white >> >> > noise. >> >> > >> >> > While one can make an IconicButton of course, one can not make a >> >> > Window >> >> > Title Bar this way. There must be a way to make it directly in code? >> >> > With >> >> > more and more high resolution displays it will get interesting some >> >> > day. >> >> > Look at the OS X Lion - Pharo comparison screenshot: >> >> > >> >> > http://forum.world.st/file/n4634551/SubtleTexture.jpg >> >> > >> >> >> >> oh .. it is indeed subtle.. i didn't get what you mean first time. >> >> yes, of course, that's possible.. just not sure if it worth to waste >> >> CPU cycles on this, as you said,Â subtle stuff. >> > >> > >> > EFLs use bitmaps to render everything, it runs fast, you don't need >> > antialiasing, and you can customize the appearance however you like. >> > Couldn't it be an inspiration? >> >> EFL? what is it.. got a link? >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.

June 13, 2012

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

by Camillo Bruni

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] Fastest utf-8 encoder contest

by Igor Stasenko

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. > In Seaside 3.1 we go one step further. Imagine you have a long > ByteString and only few non-ASCII characters. We do not want to have to > copy the whole string just to utf-8 encode a few characters, so we > combine the above approach with #next:putAll:startingAt: so that we only > have to encode and copy the non-ASCII characters, everything else is not > copied. > > I have become quite paranoid about allocation in Pharo. If I can remove > about two or three #streamContents: I can get about 100 to 200 req/s more. > > Â [1] This seems to be true for the rendering code in Seaside since it > renders many small snippets. Even if you have several non-ASCII strings > on a page since each string is rendered individually all the rest will > still be ASCII. > > Cheers > Philippe > > -- Best regards, Igor Stasenko.

June 13, 2012

[Pharo-project] WriteStream, nextPutAll:, OrderedCollections

by Guillermo Polito

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