- Pharo-dev - lists.pharo.org

Re: [Pharo-project] The Cult of Done Manifesto

by Sven Van Caekenberghe

Cool, both posters are nice as well, especially the graphical one with the Rubik's Cubes. On 18 May 2011, at 13:17, Marcus Denker wrote: > The Cult of Done Manifesto > > - There are three states of being. Not knowing, action and completion. > > - Accept that everything is a draft. It helps to get it done. > > - There is no editing stage. > > - Pretending you know what you're doing is almost the same as knowing what you are doing, > so just accept that you know what you're doing even if you don't and do it. > > - Banish procrastination. If you wait more than a week to get an idea done, abandon it. > > - The point of being done is not to finish but to get other things done. > > - Once you're done you can throw it away. > > - Laugh at perfection. It's boring and keeps you from being done. > > - People without dirty hands are wrong. Doing something makes you right. > > - Failure counts as done. So do mistakes. > > - Destruction is a variant of done. > > - If you have an idea and publish it on the internet, that counts as a ghost of done. > > - Done is the engine of more. > > http://www.brepettis.com/blog/2009/3/3/the-cult-of-done-manifesto.html?v=1

May 18, 2011

[Pharo-project] Circle is gone

by Tudor Girba

Hi, Circle seems to be gone from Pharo 1.3. What is now the preferred way to specify a circle? Cheers, Doru -- www.tudorgirba.com "When people care, great things can happen."

May 18, 2011

Re: [Pharo-project] Basic tricks for improving a serializer?

by Sven Van Caekenberghe

Mariano, On 18 May 2011, at 14:29, Mariano Martinez Peck wrote: > Sven, I improved quite a lot using your buffered write stream. > What I don't understans is why MultiByteFileStream doesn't perform as good as them. > If I see StandardFileStream has an internal buffer called 'buffer1'. > > So why is that much difference between using MultiByteFileStream directly and > a WriteStream (ByteArray new writeSteam ) or ZnBufferedWriteStream ? I just looked briefly at the hierarchy, it seems that buffer1 is an output buffer of size 1 ! Have a look at StandardFileStream>>#nextPut: char "Write the given character to this file." rwmode ifFalse: [^ self error: 'Cannot write a read-only file']. collection ifNotNil: [ position < readLimit ifTrue: [ self flushReadBuffer ] ]. buffer1 at: 1 put: char. self primWrite: fileID from: buffer1 startingAt: 1 count: 1. ^ char There is simply no buffering going on. buffer1 is a mystery to me ;-) Sven BTW: the above method flushes the READ buffer while WRITING, there is probably an explanation for this, but I can't think of one.

May 18, 2011

Re: [Pharo-project] Basic tricks for improving a serializer?

by Mariano Martinez Peck

On Tue, May 17, 2011 at 3:34 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > Mariano, > > On 17 May 2011, at 15:21, Mariano Martinez Peck wrote: > > > Now Igor told us for example, to use a buffer like this: > > > > | bufferStream | > > bufferStream := ByteArray new writeStream. > > > > (FLSerializer on: bufferStream) > > serialize: anArrayToSerialize. > > > > aFileStream nextPutAll: bufferStream contents. > > > > and that it at least 2 times faster than we were doing.... I guess it is > because it goes to the disk only once. But MultiByteFileStream uses a > buffer, doesn't it ? > > The disadvantage of the above is that you buffer everything before you > write. Furthermore you are growing the buffer all the time (recopying > contents) which is not too efficient. > > Some time ago we had a discussion about this and then I implemented > ZnBufferedWriteStream (it should be in Core 1.3), have a look. It was just a > quick hack, but it worked in speeding up writing. > > Sven, I improved quite a lot using your buffered write stream. What I don't understans is why MultiByteFileStream doesn't perform as good as them. If I see StandardFileStream has an internal buffer called 'buffer1'. So why is that much difference between using MultiByteFileStream directly and a WriteStream (ByteArray new writeSteam ) or ZnBufferedWriteStream ? Thanks -- Mariano http://marianopeck.wordpress.com

May 18, 2011

Re: [Pharo-project] Branded Cog for Win32 for Build slave (Was: [TODO] 1.3)

by Mariano Martinez Peck

On Wed, May 18, 2011 at 2:14 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On May 18, 2011, at 10:44 AM, Torsten Bergmann wrote: > > >> provide a "Pharo Cog $VersionNumber" vm. > >> > >> The good news is that we now have a window build slave, so we will soon > have >all 3 major architectures covered > > > > Nice - the windows build slave arrived! Who maintains it? > > > The server is maintained by INRIA it services... the build infrastructure > by Igor and the rest who has > access (i.e. me, but I stopped using windows *before* win95 was > released...) > > heheheheh HAHHAHAHA what a lucky guy > > So I expect the build slave to > > 1. get the code from Eliots svn repository > > 2. patch the code to "brand" the vm with custom Pharo icon and label > > 3. Replace the name of the VM to build in the Makefile > > 4. build it for use in OneClick or installer or to provide a zip > > > > yes. > > Marcus > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Mariano http://marianopeck.wordpress.com

May 18, 2011

Re: [Pharo-project] Branded Cog for Win32 for Build slave (Was: [TODO] 1.3)

by Marcus Denker

On May 18, 2011, at 10:44 AM, Torsten Bergmann wrote: >> provide a "Pharo Cog $VersionNumber" vm. >> >> The good news is that we now have a window build slave, so we will soon have >all 3 major architectures covered > > Nice - the windows build slave arrived! Who maintains it? > The server is maintained by INRIA it services... the build infrastructure by Igor and the rest who has access (i.e. me, but I stopped using windows *before* win95 was released...) > So I expect the build slave to > 1. get the code from Eliots svn repository > 2. patch the code to "brand" the vm with custom Pharo icon and label > 3. Replace the name of the VM to build in the Makefile > 4. build it for use in OneClick or installer or to provide a zip > yes. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 18, 2011

Re: [Pharo-project] A lil simplification of MorphTreeNodeMorph

by Tudor Girba

Hi, In this thread, there were several cs proposed. I thought they were integrated in 1.3, but they do not seem to be there. I was so looking forward to using them :). Igor, could you take a look? Cheers, Doru On 6 Apr 2011, at 13:43, Igor Stasenko wrote: > Okay, here the updated version. > > > GTCoder open > looks fine > > Settings look fine. > and > > SimpleGridExample new open > looking fine as well > > -- > Best regards, > Igor Stasenko AKA sig. > <theTreee.8.cs> -- www.tudorgirba.com "Be rather willing to give than demanding to get."

May 18, 2011

[Pharo-project] [Hudson] Filesystem testrunner

by Marcus Denker

https://pharo-ic.lille.inria.fr/hudson/job/Filesystem/ 1.3, rebuild after every core update. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 18, 2011

Re: [Pharo-project] Decompiler problem (leading to infinite loop of opening debuggers)

by Johan Brichau

thanks guys! I didn't test in 1.3 indeed. btw, since moving to 1.2, after doing pullup or pushdown refactorings, I often get methods that badly reference instance variables. Their instvar index seems to be off in the sense that the name references another variable. I can fix the problem by recompiling the method but it's quite a pain. Unfortunately, I have been unsuccessful in creating a scenario that always works... I hope to do that asap.

May 18, 2011

Re: [Pharo-project] Decompiler problem (leading to infinite loop of opening debuggers)

by Marcus Denker

On May 18, 2011, at 1:32 PM, Toon Verwaest wrote: > On 05/18/2011 01:30 PM, Marcus Denker wrote: >> On May 18, 2011, at 1:26 PM, Toon Verwaest wrote: >> >>> I haven't figured out the exact decompiler bug yet, but just so you can easily fix your problem: >>> >> I tested on 1.3, and it's fixed there... we synced in 1.3 with some fixes from the old compiler. >> >> We could backport the compiler fixes to 1.2... > Oh ok, then I don't even look further. But that decompiler is a mess ... moving to OPAL would be a great improvement I'd say ... :-) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 18, 2011