February 2013 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20536

by Marcus Denker

20536 ----- Issue 7025: Monticello does not load Trait related method deletions correctly http://code.google.com/p/pharo/issues/detail?id=7025

Feb. 11, 2013

[Pharo-project] Clock/Delay problems

by Sven Van Caekenberghe

I have seen this before, and it is probably related to other problems that we have been seeing lately: Basically the whole initialization of DateAndTime (class side) goes wrong. Could this have something to do with Delay problems ? Some time ago, there were some Delay changes, right ? I have not yet made an issue, as I think we should discuss a bit first. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Feb. 11, 2013

Re: [Pharo-project] Migrated HashTable from ss to SmalltalkHub

by Marcus Denker

On Feb 11, 2013, at 1:34 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I can dig up all my benchmarks from my master ;) but I remember that we were > faster on most operations or the same speed in the worst case. I have benchmarks > for every possible case :P (that's a bit exaggerated), but there are 42 different > micro benchmarks which stress most dictionary aspects. > > For operations like iterating over the keys/values of a dictionary we are > 5 times faster (less overhead due to fixed structures) > > #includes on Set was also considerably faster in our implementation. and of course degeneration due to the bad hashing should be much better handledâ¦ the current implementation, when it starts to have collision, it will make more collisions even more likely by using a free slot. And in case of collision, the buckets should be much faster to find something as with linear seating the entry can be much further away then just the number of colliding for one entry. Marcus

Feb. 11, 2013

Re: [Pharo-project] Migrated HashTable from ss to SmalltalkHub

by Camillo Bruni

I can dig up all my benchmarks from my master ;) but I remember that we were faster on most operations or the same speed in the worst case. I have benchmarks for every possible case :P (that's a bit exaggerated), but there are 42 different micro benchmarks which stress most dictionary aspects. For operations like iterating over the keys/values of a dictionary we are 5 times faster (less overhead due to fixed structures) #includes on Set was also considerably faster in our implementation. On 2013-02-10, at 18:19, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > provide benchs and we will take adequate action :) > > Not you camillo :) > > Stef > > On Feb 10, 2013, at 5:07 PM, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > >> Interesting, nice thesis Camilo. >> Why not replace Dictionary then? At least it should be integrated into Collections, in the image. >> Fernando >> >> >> >> On Sun, Feb 10, 2013 at 4:38 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >> On 2013-02-10, at 16:34, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> >>> >>> On Feb 10, 2013, at 4:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> >>>> On 10 Feb 2013, at 15:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> - migrated all the history >>>>> - defined configurationOf >>>>> - All tests are green under 1.4 and 2.0 >>>>> >>>>> Stef >>>> >>>> Dear I ask: what is HastTable and how it is different from Dictionary ? >> >> >> I think it's a dictionary implementation based on buckets (as any other decent >> dictionary implementation does...) >> >> I've shown in my master thesis that a simple bucket-based dictionary can outperform >> our poor-mans single array collection dictionary in almost every operation. The only >> drawback is the slightly bigger size in memory. >> >> http://scg.unibe.ch/archive/masters/Brun11a.pdf >> >

Feb. 11, 2013

Re: [Pharo-project] OneClick for 2.0 available again

by Marcus Denker

On Mon, Feb 11, 2013 at 12:32 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hannes wrote >>Thorsten, >> >>reading what you have written, am I right that we just need a >> NBCog.ini >> >>file for MSwindows? > > We already have an INI file in the Pharo 2.0 one-click. > This INI file contains the correct entry about where to find the image file. > > But it is named "CogVM.ini" instead of "NBCog.ini" since according to the > naming convention it has to be named like the VM (which is currently NBCog.exe). > > So as I wrote just rename CogVM.ini into NBCog.ini and it works. > > I did this now and the next build should have the right ini Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Feb. 11, 2013

[Pharo-project] [update 2.0] #20535

by Marcus Denker

20535 ----- Issue 7484: One Click on Windows: Make sure it works http://code.google.com/p/pharo/issues/detail?id=7484 Issue 6657: [ENH] Spec Request : make nextFocus / previousFocus Keymapping-based http://code.google.com/p/pharo/issues/detail?id=6657 Diff information: http://ss3.gemstone.com/ss/Pharo20/Spec-Widgets-MarcusDenker.98.diff http://ss3.gemstone.com/ss/Pharo20/Spec-Tools-MarcusDenker.89.diff http://ss3.gemstone.com/ss/Pharo20/Spec-Core-MarcusDenker.82.diff http://ss3.gemstone.com/ss/Pharo20/CI-Core-MarcusDenker.60.diff

Feb. 11, 2013

[Pharo-project] OneClick for 2.0 available again

by Torsten Bergmann

Hannes wrote >Thorsten, > >reading what you have written, am I right that we just need a > NBCog.ini > >file for MSwindows? We already have an INI file in the Pharo 2.0 one-click. This INI file contains the correct entry about where to find the image file. But it is named "CogVM.ini" instead of "NBCog.ini" since according to the naming convention it has to be named like the VM (which is currently NBCog.exe). So as I wrote just rename CogVM.ini into NBCog.ini and it works. Bye Torsten (without h)

Feb. 11, 2013

Re: [Pharo-project] OneClick for 2.0 available again

by H. Hirzel

Thorsten, reading what you have written, am I right that we just need a NBCog.ini file for MSwindows? I'll have a look how it is done in the Squeak 4.3-All-in-one and try to do it accordingly. http://ftp.squeak.org/4.3/Squeak-4.3-All-in-One.zip --Hannes On 2/11/13, Torsten Bergmann <astares(a)gmx.de> wrote: > Hannes wrote: > >>If I open the Pharo one click 2.0 on Windows by double-clicking on >>'NBCog' I get a 'Choose file' dialog > > Yes, this is a problem with the (current) double-click build. > See my post here: > > > http://lists.gforge.inria.fr/pipermail/pharo-project/2013-February/074358.h… > > Quick fix is to just rename CogVM.ini into NBCog.ini and it works. > We should make sure the INI file is always named like the VM. > > Background: > =========== > > The (Windows) VM executable (if I remember the code correctly) looks > for the image file like this: > > 1. If there is an *.ini file that is named like the VM executable > (for instance NBCog.exe -> NBCog.ini or Pharo.exe -> Pharo.ini) > then this INI-File is processed to initialize the VM. > > If this ini File contains an entry called "ImageFile" > then it searches for the location given there. > > This is from old Squeak times and described here: > http://squeakvm.org/win32/settings.html > > 2. If there is no ini File it looks in the current directory > (usually the directory where the VM executable is placed when you > double click in explorer) > for a file with an *.image extension. > > If it finds exactly one then this is started. You can try this > if you extract a VM and an image in the same directory. > > If the Windows VM does not find an image file or more than one files > with the > *.image extension (after multiple saves) then a file dialog is > opened. > > This is absolut correct - but in the Pharo one-click the image > is unfortunately not in the same folder as the VM. > > The directory layout for Pharo one-click uses a special > "Contents\Resources\" > subfolder for the image - maybe to have a cleaner root folder. > This conflicts with this default searches... > > So if there is no ini file found and no image then it opens the file > dialog. > > Bye > T. > > >

Feb. 11, 2013

[Pharo-project] Experience using multiple images as a distributed datastore?

by Stephan Eggermont

Hi, I'm looking at alternative ways to break through the 4G 1 core border. Does anyone have recent experience storing data in multiple images and parallelizing calculations, perhaps similar to https://www.usenix.org/system/files/.../nsdi12-final138.pdf? With Ghost, Fuel and Zinc the building blocks seem to be there. Stephan

Feb. 11, 2013

Re: [Pharo-project] [Elsewhere] The Web Is Becoming SmallTalk | Zackâs Blog

by H. Hirzel

Thanks Sven for the link. Yes, a one-page HTML/JavaScript/CSS application can be compared in a modest way the work with a Smalltalk image. But for us this means to stay with Smalltalk where it is possible as it offers much more. This issue is something for the Amber list, I think. --Hannes On 2/11/13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > As read on new.ycombinator.com > > http://zacharyvoase.com/2013/02/10/smallweb/ >

Feb. 11, 2013