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

Re: [Pharo-project] Problem with Arch Linux and Cog

by laurent laffont

For ArchLinux as a starting point I've seen there's a squeakvm package in AUR https://aur.archlinux.org/packages.php?ID=44187 Laurent On Wed, Jan 11, 2012 at 1:25 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Jan 11, 2012, at 12:25 PM, Milan Mimica wrote: > > > This is what you get for trying to make a binary that just works on any > x86 Linux distribution. It won't work. Vendors don't like it, Linus doesn't > like it, RMS hates it :) The proper fix to all of this problems would be to > provide distribution specific packages. I know that's a lot more of work > and many more people should be involved into this, but how hard can it be? > Any piece of software aimed to linux has packages for most popular > distributions, so it is doable. And once you provide a decent package, > vendors may take over it and make it official and maintain it for you. > > I could do the Slackware package. > > > excellent > what we should do is that the package is automatically created using > jenkins. > > > > > PS. I do love on-click paradigm. Too bad it doesn't work. > > > > > > On 11 January 2012 04:20, Robert Sirois <watchlala(a)hotmail.com> wrote: > > I've been trying to work around this problem, but it can't be ignored > now. I've also noticed that any exceptions thrown in the image cause a > crash as well. > > > > Was there any solution, or is the solution to not use Arch Linux? > > > > Related to this thread: > > > > > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033009.… > > > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033361.… > > > > Thanks, > > RS > > > > > > > > -- > > Milan Mimica > > http://sparklet.sf.net > > >

Jan. 11, 2012

Re: [Pharo-project] Problem with Arch Linux and Cog

by StÃ©phane Ducasse

On Jan 11, 2012, at 12:25 PM, Milan Mimica wrote: > This is what you get for trying to make a binary that just works on any x86 Linux distribution. It won't work. Vendors don't like it, Linus doesn't like it, RMS hates it :) The proper fix to all of this problems would be to provide distribution specific packages. I know that's a lot more of work and many more people should be involved into this, but how hard can it be? Any piece of software aimed to linux has packages for most popular distributions, so it is doable. And once you provide a decent package, vendors may take over it and make it official and maintain it for you. > I could do the Slackware package. excellent what we should do is that the package is automatically created using jenkins. > > PS. I do love on-click paradigm. Too bad it doesn't work. > > > On 11 January 2012 04:20, Robert Sirois <watchlala(a)hotmail.com> wrote: > I've been trying to work around this problem, but it can't be ignored now. I've also noticed that any exceptions thrown in the image cause a crash as well. > > Was there any solution, or is the solution to not use Arch Linux? > > Related to this thread: > > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033009.… > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033361.… > > Thanks, > RS > > > > -- > Milan Mimica > http://sparklet.sf.net

Jan. 11, 2012

Re: [Pharo-project] DateAndTime, timezones and Fuel

by Sven Van Caekenberghe

Hey Mariano, On 11 Jan 2012, at 12:41, Mariano Martinez Peck wrote: > Hi guys. I have a simple question. When we are serializing DateAndTime with fuel, we serialize its 4 instance variables: 'seconds offset jdn nanos'. And then, during materialization, we recreate them. I know that all instances of DateAndTime have their instVar 'offset' pointing to the local timezone offset, that is, DateAndTime localTimeZone offset. In fuel, during materialization, we recreate those offsets. So all materialized instances of DateAndTime will have their own (different) instance of Duration in the slot 'offset'. On the one hand, I think this is necessary becase you can materialize in a different image with different time zone, so having the timezone is mandatory. What I don't know, and this is the question, is if the timezone is the same between serialization and materialization image, MUST all materializated DateAndTime point to the same offset? or it is just an optimization that they all point to the same? > > Thanks in advance, > > -- > Mariano > http://marianopeck.wordpress.com To answer the question first: I think its only an optimization, not a requirement. (But the system should share them ;-) But I don't understand: if you serialize all 4 inst vars, and if the offsets would be shared before, then they would be shared after materialization as well, no ? Also note that it is certainly not an invariant that all offsets of all instances of DateAndTime are equal to the local offset, most of the time we are using offset 0 (UTC), for example. Serialization of a DateAndTime from an image with local TZ 1 and dematerializaing in another image with local TZ 2 will still work in the sense that the time is correct, the instances in the new image will just have a non-local TZ. They could be converted to the local TZ, but I don't think this should happen by default. Sven

Jan. 11, 2012

[Pharo-project] DateAndTime, timezones and Fuel

by Mariano Martinez Peck

Hi guys. I have a simple question. When we are serializing DateAndTime with fuel, we serialize its 4 instance variables: 'seconds offset jdn nanos'. And then, during materialization, we recreate them. I know that all instances of DateAndTime have their instVar 'offset' pointing to the local timezone offset, that is, DateAndTime localTimeZone offset. In fuel, during materialization, we recreate those offsets. So all materialized instances of DateAndTime will have their own (different) instance of Duration in the slot 'offset'. On the one hand, I think this is necessary becase you can materialize in a different image with different time zone, so having the timezone is mandatory. What I don't know, and this is the question, is if the timezone is the same between serialization and materialization image, MUST all materializated DateAndTime point to the same offset? or it is just an optimization that they all point to the same? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

Jan. 11, 2012

Re: [Pharo-project] Problem with Arch Linux and Cog

by Milan Mimica

This is what you get for trying to make a binary that just works on any x86 Linux distribution. It won't work. Vendors don't like it, Linus doesn't like it, RMS hates it :) The proper fix to all of this problems would be to provide distribution specific packages. I know that's a lot more of work and many more people should be involved into this, but how hard can it be? Any piece of software aimed to linux has packages for most popular distributions, so it is doable. And once you provide a decent package, vendors may take over it and make it official and maintain it for you. I could do the Slackware package. PS. I do love on-click paradigm. Too bad it doesn't work. On 11 January 2012 04:20, Robert Sirois <watchlala(a)hotmail.com> wrote: > I've been trying to work around this problem, but it can't be ignored > now. I've also noticed that any exceptions thrown in the image cause a > crash as well. > > Was there any solution, or is the solution to not use Arch Linux? > > Related to this thread: > > > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033009.… > > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033361.… > > Thanks, > RS > -- Milan Mimica http://sparklet.sf.net

Jan. 11, 2012

Re: [Pharo-project] Happy new year!

by Andrea BrÂÃ¼hlmann

Hi Thanks! I wish you all a good year, too! And to add a thought about life: "Die Hauptsache ist, dass die Hauptsache zur Hauptsache wird" (I don't remember who said this) (The main point is that the main point becomes the main point) :-) Andrea StÃ©phane Ducasse schrieb: > Hi guys > > I wish you good health (because at the end this is the most important and when we are going well we do not > estimate how cool it is). > Then lot of fun and business. > > Stef > >

Jan. 11, 2012

Re: [Pharo-project] NativeBoost and NBOpenGL on Mac?

by Fernando Olivero

I've developed a CocoaUI app, which implements the example you copied. A cocoa window, with a custom NSView, which renders an OpenGL surface. The app also catches events, and notifies it via sockets. My idea is to render within Pharo to a frame buffer object(offscreen rendering), and communicate the redisplay to the cocoa app via sockets (IPC). So we can code all the UI in Smalltalk, using offscreen rendering as a means to draw to a native OS X window. I will continue experimenting with this approach, to assess its performance and usability. Wether IPC via sockets is fast enough, amongst other technical challenges. Yes, i noticed two that the OpenGL info in the Mac, returns 'APPLE SOFTWARE RENDERER 2.1". Surely we can find a way to solve this problem, i will look into Lawson's link. Fernando pd: Enjoy the vacations Igor, have a pint or two. On Wed, Jan 11, 2012 at 1:21 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 10 January 2012 21:28, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> thanks >> >> May be this page is interesting: http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conce… >> >> Igor how is london :) ? >> >> Crowded? > > like hell. :) > Kiev is more or less same in this regard, so i already having immunity > > Yes, i will definitely get back to this issue, once i return from vacation. > And now i should stop reading and replying mails and spend time on > just resting :) > > -- > Best regards, > Igor Stasenko. >

Jan. 11, 2012

Re: [Pharo-project] [COTDC] 103 - ZLibWriteStream

by Max Leske

I use the zlib implementation of the deflate algorithm to compress a ByteArray. See http://en.wikipedia.org/wiki/DEFLATE for details on the deflate algorithm. This is how you get a compressed ByteArray from your input: zipStream := ZLibWriteStream on: (ByteArray new). zipStream nextPutAll: myByteArray; close. compressed := zipStream encodedStream contents. On 10.01.2012, at 21:36, sean(a)clipperadams.com wrote: > 102 classes done > 794 classes remaining > Continuing in Compression... > > Today: ZLibWriteStream > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > p.s. this message was sent from a pharo image. Did you know you could easily do that?! >

Jan. 11, 2012

[Pharo-project] [Tuning] Set class>>new:

by StÃ©phane Ducasse

no time to think about it but I found that interesting. Begin forwarded message: > From: Paul Baumann <paul.baumann(a)theice.com> > Subject: [vwnc] [Tuning] Set class>>new: > Date: January 11, 2012 1:11:19 AM GMT+01:00 > To: "'VWNC'" <vwnc(a)cs.uiuc.edu> > > Inspect this code to see hashed collection instances grouped by their free space percentage: > > ^((ObjectMemory allInstancesOfAny: Set withAllSubclasses asArray) asOrderedCollection > reject: [:ea | ea size < 10 ]) > groupedBy: [:ea | ea capacity / ea size - 1.0 ] > > Hashing collections in VW need to have extra space allocated to act as search limits between logical groups. Sets performance drops there are aren't many free slots allocated. When there are only 25% free slots allocated then the collection grows. VW rounds up to a prime number for instance creation and then targets 33% rounded up to a prime for growths afterwards. A target of 33% rounded to prime skimps on memory at the expense of performance. > > As a collection grows to the minimum 25% free space goal (in #fullCheck) there is a 75% chance of crossing into the next logical bucket before finding a nil value. Crossing into the next logical bucket just once can double the number of slots searched for a miss. Four logical buckets may be traversed for each search-miss by the time the 25% minimum is reached. > > When VW skimps on allocation then it has to grow collections more frequently and has to do more comparisons for each lookup. That is a general performance problem, but there is another problem with how VW allocates memory for pre-sized collections... > > When you see collections created for an expected size like these: > > anArray := Array new: 1000. > aSet := Set new: 1000. > anOc := OrderedCollection new: 1000. > aDict := Dictionary new: 1000. > > How many items would you expect each of these collections to efficiently contain? Clearly the Array will be exactly 1000. The OrderedCollection will take up to 1000 additions before it needs to grow. Pre-sized collections are created to avoid incremental growth costs. Is it not common and natural to think that the Set and Dictionary would also be created to efficiently contain 1000 items too? Would you be surprised to learn that all subclasses of Set in VW (and likely only VW) are inefficient with this kind of pre-allocation when you add 1000 objects to them? > > No application code should be expected to know how Sets are implemented and to pad sizes having knowledge of VW implementation details! Look at the capacity variances that VW creates even though the Set has been created each time to anticipate 1000 additions: > > (Set withAll: (Array new: 1000)) capacity > 1511 > > (Set withAll: ((1 to: 1000) collect: [:i | Object new ])) capacity > 1511 > > (Set new: 1000) capacity > 1009 > > ((Set new: 1000) addAll: ((1 to: 1000) collect: [:i | Object new ]); yourself) capacity > 2027 > > ((Set new) addAll: ((1 to: 1000) collect: [:i | Object new ]); yourself) capacity > 1361 > > The first four should all have the same result. The last one can be different because it is not pre-sized. The third example shows that only 0.9% free space is allocated in addition to the requested size. The fourth example shows that the under-allocation caused a growth that then over-allocated to end at 102.7% free space. The costs of the third and fourth example can be seen in more detail with this test: > > | objects set timings cap0 t0 t1 | > objects := (1 to: ObjectMemory maximumIdentityHashValue) collect: [:i | Object new]. > timings := OrderedCollection new: objects size. > t0 := t1 := Time microsecondClock. > set := Set new: objects size. > cap0 := set capacity. > objects size to: 1 by: -1 do: [ :i | > set add: (objects at: i). > i \\ 1000 = 1 ifTrue: [timings add: (t1 negated + (t1 :=Time microsecondClock))]. > ]. > (Array new: 5) > at: 1 put: cap0; "Starting capacity" > at: 2 put: set capacity; "Ending capacity" > at: 3 put: (1 - (set capacity / set size) * -100.0); "Percentage of free slots" > at: 4 put: timings asArray; "Timings of each 1000" > at: 5 put: t1 - t0; "Total time" > yourself > > #(17417 34939 113.264 #(147 264 262 261 262 262 265 261 261 260 261 260 260 2474 184 184 184) 6312) "primes" > > A difference between the first and second numbers indicates growth costs were incurred while adding. The third number shows there were 1.13 free slots allocated for each logical bucket. The last number is total execution time. Notice that performance of each group improves 41% just after the collection grows. > > Load a package named ICXVwHashTuning from the Cincom Public Code Repository and try the test again. > > #(28670 28670 74.9985 #(104 182 179 179 180 263 180 183 185 184 190 189 188 188 189 254 188) 3205) "After loading ICXVwHashTuning" > > Total execution time was cut by 49% while consuming 18% less memory and ending with a (very efficient) 75% free slots. > > When application code says "Set new: 1000" then they mean that they want a Set instance that should expect to contain 1000 additions. It is the responsibility of the Set to know how much physical space should be allocated to contain 1000 items. These are simple changes that make a broad performance improvement while also having intuitive performance. Cincom should take notice of opportunities like this but at least you can improve the performance of your existing code if they don't. > > You might want to also execute "(ObjectMemory allInstancesOfAny: Set withAllSubclasses asArray) do: [:ea | ea trim ]." to optimize free space allocation for all the hashed instances. You may notice a performance boost from doing that once after loading ICXVwHashTuning. > > Paul Baumann > > > This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Jan. 11, 2012

Re: [Pharo-project] Problem with Arch Linux and Cog

by Schwab,Wilhelm K

You've clearly done the first thing I was going to recommend, which was to run Pharo from a terminal to capture any diagnostic output. The next step would be strace, which might reveal the vm's thoughts. Use either the -o option or redirect standard error to a file; strace writes nothing to stdout - you've been warned :) Once you get the output, it will be verbose, but grep is your friend in that case. You probably know this, something like cat strace-log.txt | grep uuid could be revealing. It might show where Cog thinks the library lives. It's ugly, but if you know where Cog insists on looking, then you can put symlink there and *maybe* get going. I just hit the problem I am describing (and suspect could be ailing you) on Ubuntu and hacked around it that way. Thanks to Nick for the strace pointer. If you are not sure if/where the UUID library lives, you can try the locate command, or otherwise scrounge around. If the library is not on the machine, that might be the problem. HTH. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Robert Sirois [watchlala(a)hotmail.com] Sent: Tuesday, January 10, 2012 10:20 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Problem with Arch Linux and Cog I've been trying to work around this problem, but it can't be ignored now. I've also noticed that any exceptions thrown in the image cause a crash as well. Was there any solution, or is the solution to not use Arch Linux? Related to this thread: http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033009.… http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033361.… Thanks, RS

Jan. 11, 2012