- Pharo-dev - lists.pharo.org

Re: [Pharo-project] CI server down?

by Marcus Denker

Yes, it's dead. On Dec 2, 2012, at 10:51 PM, Sebastian Nozzi <sebnozzi(a)gmail.com> wrote: > I cannot access: > > http://ci.lille.inria.fr/pharo/ > > (anyone has nagios on that? ;-) > I have a what dog on it and I send a mail to it every time something stops working (which now is just hours after it is "fixed"â¦). So, it's dead. We should move everything here: https://ci.inria.fr/pharo/ Sadly I have no time to work on it last week or this week. Marcus

Dec. 3, 2012

Re: [Pharo-project] Pharo Association

by Marcus Denker

On Dec 3, 2012, at 8:02 AM, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > > The print out, sign and sending the document is understood. > > Where can I pay for individual members by credit card and where. > Hello, For individuals, the way to support Pharo is not the consortium (as Inria can not handle small payments and especially no credit cards): http://association.pharo.org > Can this also be done for bulk payment for multiple membership, if I can convince a few more locally > > > > > On Thu, Nov 15, 2012 at 7:21 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hello, > > We are happy to announce the Pharo User Association: > > http://association.pharo.org > > The goal of the Pharo User Association is to support Pharo development and > promotion. > > There are two individual memberships > > - Individual Pharo Association Member: Yearly fee 40 Euros > - Golden Individual Pharo Association Member: Yearly fee 99 Euros > > You will get > - reduction access to pharo conferences, > - reduction for training and access to teaching material, > - be part of the pharoAssociation-individual-members mailing-list, > - an account at the pharo association web site. > > This Association is complementary to the Pharo consortium managed by INRIA. > The Consortium is for entities such as companies, research teams, or institutes. > For more information, see: http://www.pharo-project.org/community/consortium > > The funds collected by the Association will be used in coordination with the Consortium > to support the development of Pharo. > > The Pharo Board and Pharo Core Team. > > >

Dec. 3, 2012

Re: [Pharo-project] Pharo Association

by S Krish

The print out, sign and sending the document is understood. Where can I pay for individual members by credit card and where. Can this also be done for bulk payment for multiple membership, if I can convince a few more locally On Thu, Nov 15, 2012 at 7:21 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > Hello, > > We are happy to announce the Pharo User Association: > > http://association.pharo.org > > The goal of the Pharo User Association is to support Pharo development and > promotion. > > There are two individual memberships > > - Individual Pharo Association Member: Yearly fee 40 Euros > - Golden Individual Pharo Association Member: Yearly fee 99 Euros > > You will get > - reduction access to pharo conferences, > - reduction for training and access to teaching material, > - be part of the pharoAssociation-individual-members mailing-list, > - an account at the pharo association web site. > > This Association is complementary to the Pharo consortium managed by INRIA. > The Consortium is for entities such as companies, research teams, or > institutes. > For more information, see: > http://www.pharo-project.org/community/consortium > > The funds collected by the Association will be used in coordination with > the Consortium > to support the development of Pharo. > > The Pharo Board and Pharo Core Team. > > >

Dec. 3, 2012

Re: [Pharo-project] Performance Tip: Using buffered streams

by Sven Van Caekenberghe

Hi Mariano, On 02 Dec 2012, at 23:43, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > This is really really interesting, because it means a speed up of 2x when reading :) > Where can I get the last version of ZnBufferedReadStream? I knew you would be interested: it is in the latest Zn, either http://mc.stfx.eu or squeaksource (not in the metacello yet). It should work on binary streams too, I don't know whether it would make a lot of difference, I would guess so. Maybe Fuel uses lots of 'deterministic reading' (size prefixed) instead of parsing. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 3, 2012

[Pharo-project] New Cog VMs available

by Eliot Miranda

...in http://www.mirandabanda.org/files/Cog/VM/VM.r2628. These fix a bug with pc mapping that could cause the Vm to crash on simple loops containing arithmetic on constants (e.g. 1 to: 20 do: [:i| 1=1]). They also cause the instantiation primitives to pop all their arguments rather than assume their argument count is 0 or 1. More change info available in the directory. -- best, Eliot

Dec. 3, 2012

[Pharo-project] using a long running native thread - NativeBoost or Plugin?

by drush66

Would it be possible to start native thread inside pharo? This thread would run (for quite a long time) some event loop (like the libev), and post some info to the SharedQueue. Smalltalk code would in turn be reading stuff from this queue. You could say it would be pumping events from libev to SharedQueue instance for Smalltalk code to consume. Is this doable? With NativeBoost or Plugin? I have also found some info on threaded VM, but if I understand it correctly it seems more oriented to provide a thread to execute FFI call on it. ----- http://www.cloud208.com/ -- View this message in context: http://forum.world.st/using-a-long-running-native-thread-NativeBoost-or-Plu… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 2, 2012

Re: [Pharo-project] Performance Tip: Using buffered streams

by Mariano Martinez Peck

On Sun, Dec 2, 2012 at 11:09 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > <short-version> > > When doing complex IO, like writing or parsing protocols, to non-memory > streams, like file streams (and probably socket streams), buffering can > make an important difference. ZnBufferedWriteStream and > ZnBufferedReadStream are an easy solution to experience the difference. > Yes, I noticed that in Fuel and that's why we use the buffered write stream always. It was a huge difference. > > </short-version> > > And now the long version: first some measurements (code based on latest > versions of Zinc, NeoCSV, NeoJSON and STON): > > NeoJSON > > | data | > data := (1 to: 25000) collect: [ :each | > { each. each negated. each reciprocal asFloat. each sqrt. each > asWords } ]. > [ '/tmp/numbers.json' asFileReference writeStreamDo: [ :stream | > (NeoJSONWriter on: stream) nextPut: data ] ] timeToRun. 22152 > > | data | > data := (1 to: 25000) collect: [ :each | > { each. each negated. each reciprocal asFloat. each sqrt. each > asWords } ]. > [ '/tmp/numbers.json' asFileReference writeStreamDo: [ :fstream | > ZnBufferedWriteStream on: fstream do: [ :stream | > (NeoJSONWriter on: stream) nextPut: data ] ] ] timeToRun. > 5147 > > [ '/tmp/numbers.json' asFileReference readStreamDo: [ :stream | > (NeoJSONReader on: stream) next ] ] timeToRun. 3502 > > [ '/tmp/numbers.json' asFileReference readStreamDo: [ :fstream | > ZnBufferedReadStream on: fstream do: [ :stream | > (NeoJSONReader on: stream) next ] ] ] timeToRun. 1214 > > STON > > | data | > data := (1 to: 25000) collect: [ :each | > { each. each negated. each reciprocal asFloat. each sqrt. each > asWords } ]. > [ '/tmp/numbers.ston' asFileReference writeStreamDo: [ :stream | > STON writer on: stream; nextPut: data ] ] timeToRun. 22275 > > | data | > data := (1 to: 25000) collect: [ :each | > { each. each negated. each reciprocal asFloat. each sqrt. each > asWords } ]. > [ '/tmp/numbers.ston' asFileReference writeStreamDo: [ :fstream | > ZnBufferedWriteStream on: fstream do: [ :stream | > STON writer on: stream; nextPut: data ] ] ] timeToRun. 5501 > > [ '/tmp/numbers.ston' asFileReference readStreamDo: [ :stream | > STON reader on: stream; next ] ] timeToRun. 3632 > > [ '/tmp/numbers.ston' asFileReference readStreamDo: [ :fstream | > ZnBufferedReadStream on: fstream do: [ :stream | > STON reader on: stream; next ] ] ] timeToRun. 1367 > > NeoCSV > > | data | > data := (1 to: 25000) collect: [ :each | > { each. each negated. each reciprocal asFloat. each sqrt. each > asWords } ]. > [ '/tmp/numbers.csv' asFileReference writeStreamDo: [ :stream | > (NeoCSVWriter on: stream) nextPutAll: data ] ] timeToRun. 20916 > > | data | > data := (1 to: 25000) collect: [ :each | > { each. each negated. each reciprocal asFloat. each sqrt. each > asWords } ]. > [ '/tmp/numbers.csv' asFileReference writeStreamDo: [ :fstream | > ZnBufferedWriteStream on: fstream do: [ :stream | > (NeoCSVWriter on: stream) nextPutAll: data ] ] ] > timeToRun. 5559 > > [ '/tmp/numbers.csv' asFileReference readStreamDo: [ :stream | > (NeoCSVReader on: stream) > addIntegerField; addIntegerField; addFloatField; > addFloatField; addField; > upToEnd ] ] timeToRun. 1290 > > [ '/tmp/numbers.csv' asFileReference readStreamDo: [ :fstream | > ZnBufferedReadStream on: fstream do: [ :stream | > (NeoCSVReader on: stream) > addIntegerField; addIntegerField; addFloatField; > addFloatField; addField; > upToEnd ] ] ] timeToRun. 970 > > > The reason for these non-trivial speedups is that buffering is missing > and/or buffer management is suboptimal in the standard file stream classes. > Simply wrapping the stream with a 64Kb buffer yields results like this. We > already knew this for writing (and Fuel adapted it as well), but it seems > to make a similar, although smaller difference when reading. > This is really really interesting, because it means a speed up of 2x when reading :) Where can I get the last version of ZnBufferedReadStream? > > <side-note> > > Attentive, curious readers might ask why in this particular benchmark the > reading is so much slower than the writing - normally it should be the > inverse or at least they should be closer to each other. Lo and behold: > another performance issue: float printing (as opposed to parsing) is > extremely slow (probably partially due to its reliance on LargeInteger > arithmetic) ! > I remember Nicolas Cieller doing something about Floats and printing...maybe he improved something? > > Here is a similar benchmark with only Integers: > > | data | > data := (1 to: 25000) collect: [ :each | > { each. each negated. each + 100000. each - 100000. each asWords } > ]. > [ '/tmp/numbers.csv' asFileReference writeStreamDo: [ :fstream | > ZnBufferedWriteStream on: fstream do: [ :stream | > (NeoCSVWriter on: stream) nextPutAll: data ] ] ] > timeToRun. 311 > > [ '/tmp/numbers.csv' asFileReference readStreamDo: [ :fstream | > ZnBufferedReadStream on: fstream do: [ :stream | > (NeoCSVReader on: stream) > addIntegerField; addIntegerField; addIntegerField; > addIntegerField; addField; > upToEnd ] ] ] timeToRun. 396 > > </side-note> > > If ZnBufferedWriteStream or ZnBufferedReadStream were useful in speading > up your code, please let us know. > > Sven > > PS: There is one ZnBufferedReadStream limitation: by design, #position, > #position: or #skip: -1 and everything on top of that are NOT supported - > IMHO real streams should not (and cannot) provide these operations. A sad > consequence is that NumberParser and its subclasses (and thus Number > class>>#readFrom:) do not work. NeoJSON and STON do their own number > parsing, NeoCSV relies on a new class, NeoNumberParser, that is > independently usable, though restricted to normal numbers as opposed to the > full Smalltalk syntax. > > I want to give it a try for Fuel. > -- > Sven Van Caekenberghe > http://stfx.eu > Smalltalk is the Red Pill > > > > > -- Mariano http://marianopeck.wordpress.com

Dec. 2, 2012

[Pharo-project] Performance Tip: Using buffered streams

by Sven Van Caekenberghe

Hi, <short-version> When doing complex IO, like writing or parsing protocols, to non-memory streams, like file streams (and probably socket streams), buffering can make an important difference. ZnBufferedWriteStream and ZnBufferedReadStream are an easy solution to experience the difference. </short-version> And now the long version: first some measurements (code based on latest versions of Zinc, NeoCSV, NeoJSON and STON): NeoJSON | data | data := (1 to: 25000) collect: [ :each | { each. each negated. each reciprocal asFloat. each sqrt. each asWords } ]. [ '/tmp/numbers.json' asFileReference writeStreamDo: [ :stream | (NeoJSONWriter on: stream) nextPut: data ] ] timeToRun. 22152 | data | data := (1 to: 25000) collect: [ :each | { each. each negated. each reciprocal asFloat. each sqrt. each asWords } ]. [ '/tmp/numbers.json' asFileReference writeStreamDo: [ :fstream | ZnBufferedWriteStream on: fstream do: [ :stream | (NeoJSONWriter on: stream) nextPut: data ] ] ] timeToRun. 5147 [ '/tmp/numbers.json' asFileReference readStreamDo: [ :stream | (NeoJSONReader on: stream) next ] ] timeToRun. 3502 [ '/tmp/numbers.json' asFileReference readStreamDo: [ :fstream | ZnBufferedReadStream on: fstream do: [ :stream | (NeoJSONReader on: stream) next ] ] ] timeToRun. 1214 STON | data | data := (1 to: 25000) collect: [ :each | { each. each negated. each reciprocal asFloat. each sqrt. each asWords } ]. [ '/tmp/numbers.ston' asFileReference writeStreamDo: [ :stream | STON writer on: stream; nextPut: data ] ] timeToRun. 22275 | data | data := (1 to: 25000) collect: [ :each | { each. each negated. each reciprocal asFloat. each sqrt. each asWords } ]. [ '/tmp/numbers.ston' asFileReference writeStreamDo: [ :fstream | ZnBufferedWriteStream on: fstream do: [ :stream | STON writer on: stream; nextPut: data ] ] ] timeToRun. 5501 [ '/tmp/numbers.ston' asFileReference readStreamDo: [ :stream | STON reader on: stream; next ] ] timeToRun. 3632 [ '/tmp/numbers.ston' asFileReference readStreamDo: [ :fstream | ZnBufferedReadStream on: fstream do: [ :stream | STON reader on: stream; next ] ] ] timeToRun. 1367 NeoCSV | data | data := (1 to: 25000) collect: [ :each | { each. each negated. each reciprocal asFloat. each sqrt. each asWords } ]. [ '/tmp/numbers.csv' asFileReference writeStreamDo: [ :stream | (NeoCSVWriter on: stream) nextPutAll: data ] ] timeToRun. 20916 | data | data := (1 to: 25000) collect: [ :each | { each. each negated. each reciprocal asFloat. each sqrt. each asWords } ]. [ '/tmp/numbers.csv' asFileReference writeStreamDo: [ :fstream | ZnBufferedWriteStream on: fstream do: [ :stream | (NeoCSVWriter on: stream) nextPutAll: data ] ] ] timeToRun. 5559 [ '/tmp/numbers.csv' asFileReference readStreamDo: [ :stream | (NeoCSVReader on: stream) addIntegerField; addIntegerField; addFloatField; addFloatField; addField; upToEnd ] ] timeToRun. 1290 [ '/tmp/numbers.csv' asFileReference readStreamDo: [ :fstream | ZnBufferedReadStream on: fstream do: [ :stream | (NeoCSVReader on: stream) addIntegerField; addIntegerField; addFloatField; addFloatField; addField; upToEnd ] ] ] timeToRun. 970 The reason for these non-trivial speedups is that buffering is missing and/or buffer management is suboptimal in the standard file stream classes. Simply wrapping the stream with a 64Kb buffer yields results like this. We already knew this for writing (and Fuel adapted it as well), but it seems to make a similar, although smaller difference when reading. <side-note> Attentive, curious readers might ask why in this particular benchmark the reading is so much slower than the writing - normally it should be the inverse or at least they should be closer to each other. Lo and behold: another performance issue: float printing (as opposed to parsing) is extremely slow (probably partially due to its reliance on LargeInteger arithmetic) ! Here is a similar benchmark with only Integers: | data | data := (1 to: 25000) collect: [ :each | { each. each negated. each + 100000. each - 100000. each asWords } ]. [ '/tmp/numbers.csv' asFileReference writeStreamDo: [ :fstream | ZnBufferedWriteStream on: fstream do: [ :stream | (NeoCSVWriter on: stream) nextPutAll: data ] ] ] timeToRun. 311 [ '/tmp/numbers.csv' asFileReference readStreamDo: [ :fstream | ZnBufferedReadStream on: fstream do: [ :stream | (NeoCSVReader on: stream) addIntegerField; addIntegerField; addIntegerField; addIntegerField; addField; upToEnd ] ] ] timeToRun. 396 </side-note> If ZnBufferedWriteStream or ZnBufferedReadStream were useful in speading up your code, please let us know. Sven PS: There is one ZnBufferedReadStream limitation: by design, #position, #position: or #skip: -1 and everything on top of that are NOT supported - IMHO real streams should not (and cannot) provide these operations. A sad consequence is that NumberParser and its subclasses (and thus Number class>>#readFrom:) do not work. NeoJSON and STON do their own number parsing, NeoCSV relies on a new class, NeoNumberParser, that is independently usable, though restricted to normal numbers as opposed to the full Smalltalk syntax. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 2, 2012

Re: [Pharo-project] CI server down?

by Sebastian Nozzi

Re-forwarding to the list. Might be useful. 2012/12/2 Camillo Bruni <camillobruni(a)gmail.com>: > With a change of repeating myself, this is the main use case of http://pharo.gforge.inria.fr/ci > > wget --quiet -qO - http://pharo.gforge.inria.fr/ci/ciPharo20NBCog.sh | sh > > ./vm.sh Pharo.image save $JOB_NAME > > REPO=http://squeaksource.com/Athens > ./vm.sh $JOB_NAME.image config $REPO ConfigurationOfAthens --install=1.4 > ./vm.sh $JOB_NAME.image test --junit-xml-output "Athens-.*" > > => Zero-Conf setup with the latest VMs and the Latest images > > On 2012-12-02, at 19:03, Sebastian Nozzi <sebnozzi(a)gmail.com> wrote: >>> so don't use it to get images. All images and VMs are available offsite at >>> http://pharo.gforge.inria.fr/ci/ >> >> Cool, that's *exactly* what I was using it for... thanks for the tip! :-) >

Dec. 2, 2012

Re: [Pharo-project] CI server down?

by Camillo Bruni

yes it's dead, as usual... the old ci is veeeery unstable. so don't use it to get images. All images and VMs are available offsite at http://pharo.gforge.inria.fr/ci/ => no https transfers => faster download speed => higher availability => simple predictable urls On 2012-12-02, at 18:51, Sebastian Nozzi <sebnozzi(a)gmail.com> wrote: > I cannot access: > > http://ci.lille.inria.fr/pharo/ > > (anyone has nagios on that? ;-) >

Dec. 2, 2012