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

[Pharo4] Slots can now be saved with MC
by Marcus Denker Jan. 17, 2015

Jan. 17, 2015

Hi, After some searching for a solutionâ¦ that does not break backward-compatibility, I found a way to save classes that use slots. - if a class just uses ivar Slots, it saves it 100% backward compatible (e.g. loadable in other systems) - if a class uses a special slot or class var, it saves the definition of the slot as the variable name in the monticello model. - on load it checks if there is a space in a variable name, and if yes â> decode these as Slot/Global var definions. - the code path for non-Slot classes stays largely untouched. This is not beautiful but backward compatibleâ¦ you can even load classes with Slots in Pharo3, it then creates invalid ivar names, which of course means the code does not run but it is readable. e.g. create a class like Object subclass: #A slots: { #iv => TestSlot } classVariables: { } category: 'Playgroundâ (TestSlot is a slot that does not use up space in the instance and instead saves the state in the Slot object, which means all instances share the state. Just a small example) Limitations -> no support for class variables yet -> class instance variables not yet done, either -> nut used much, for sure there will be bugs This is in 4.0 438 Marcus

8 26

Re: [Pharo-dev] InfoWorld on Redline Smalltalk
by horrido Jan. 17, 2015

Jan. 17, 2015

I believe in Redline. I think it's a very important project, strategically. On Twitter and elsewhere, I am urging contributors to join Redline. It would be something of a tragedy if Redline failed to reach version 1.0. *We need Smalltalk on the JVM.* jamesl wrote > Hi Smalltalkers, > > Redline Smalltalk is not dead although it looks like it. > I recently made the grammar much cleaner and moved to using Antlr4 as well > as cleaning up the > internals. Yes - what is in the core project in github is dormant and I > have spun off 'stc' to contain > the the work Im doing until an appropriate time to merge back into that > main. > > I'd love some help but right now you would be limited to copying across > the runtime library and writing > tests around it as I concentrate on the bytecode generation and underlying > code - which is hard to have too many people helping with. > > I'm *very* busy in my life right now with a startup (http://mywave.me) and > personal life but I really > am trying to find the time to push this along. > > I've set myself some fitness, work and Smalltalk goals for this year and > all going well Redline will be > out in September. BUT - Please don't hate me. > > This is the Year of Smalltalk and we can change the world - one JVM at a > time ;) > > - James. > Redline Smalltalk -- View this message in context: http://forum.world.st/InfoWorld-on-Redline-Smalltalk-tp4799612p4799830.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

9 15

Re: [Pharo-dev] [squeak-dev] Context status 2015-01-16
by Chris Muller Jan. 16, 2015

Jan. 16, 2015

That sounds awesome Craig, congratulations. If you ever do a video of a reasonably-sized imprinting experiment onto your core-classes image from a modern Squeak image, I will be very interested to see it! On Fri, Jan 16, 2015 at 2:01 PM, Craig Latta <craig(a)netjam.org> wrote: > > Hoi all-- > > Context[1] is the umbrella project for Naiad (a distributed module > system for all Smalltalks[2]), Spoon (a minimal object memory that > provides the starting point for Naiad), and Lightning (a > remote-messaging framework which performs live serialization, used by > Naiad for moving methods and other objects between systems). I intend > for it to be a future release of Squeak, and a launcher and module > system for all the other Smalltalks. I'm writing Context apps for cloud > computing, web services, and distributed computation. > > Commits b7676ba2cc and later of the Context git repo[3] have: > > - Support for installable object memories as git submodule repos. > > - Submodule repos for memories for each of the known Smalltalk > dialects, with Naiad support pre-loaded. I'm currently working on > the submodules for Squeak[4] and Pharo[5]. > > - A web-browser-based console for launching and managing object > memories. > > - A WebDAV-based virtual filesystem that enables Smalltalk to appear > as a network-attached storage device, and mappings of the system > to that filesystem that make Smalltalk accessible from external > text editors (e.g., for editing code, managing processes and > object memories). > > - Remote code and process browsers. > > Live discussion at [6]. Mailing list at [7]. The newsgroup is > gmane.comp.lang.smalltalk.squeak.context. > > > Thanks for checking it out! > > -C > > [1] http://thiscontext.com > [2] http://thiscontext.com/a-detailed-naiad-description > [3] https://github.com/ccrraaiigg/context > [4] https://github.com/ccrraaiigg/3EAD9A45-F65F-445F-89C1-4CA0A9D5C2F8 > [5] https://github.com/ccrraaiigg/CFE10A14-D883-4ACE-990A-0DDA86AA362B > [6] http://squeak.slack.com > [7] mailto:context@lists.squeakfoundation.org > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > >

1 0

Fixing DNU binding in GT and Nautilus
by stepharo Jan. 16, 2015

Jan. 16, 2015

Hi in nautilus method pane and GT, when I select a global variable such as SystemOrganization and press command B + N I get DNU binding. Apparently this DNU only happen when the name does not match any class substring Transcript or Undeclared will not raise an error because we have classes having name matching the expression. Fixed included. PS: I'm dead after 1h30 train delay (after giving 6 hours lecture) today. So this mail will be sent whenever I get connected. Stef

5 7

GTInspector and TxWorkspace does not work well in Spur images
by ClÃ©ment Bera Jan. 16, 2015

Jan. 16, 2015

Right now there is support for Opal but not for the old Compiler in Spur images. GTInspector and TxWorkspace does direct references to the old compiler in Pharo-40445, for example, in GLMListingPresentation>>#withSmalltalkSearch. This is a pain because I am using spur images for my developments and I can't use some features of GTInspector. In addition, the old Compiler will be removed by default from the image in the next 6 months, so these features will not work in non spur images soon. Compiler references can be replaced, for example, by "self class compiler" or "Smalltalk compiler" depending on which compiler you want (one specific to the class with the specific class settings or a generic one).

5 6

[pharo-project/pharo-core]
by GitHub Jan. 16, 2015

Jan. 16, 2015

Branch: refs/tags/40449 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core] 28434c: 40449
by GitHub Jan. 16, 2015

Jan. 16, 2015

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 28434c8f56c2caae222befb157bbbab48d496dc1 https://github.com/pharo-project/pharo-core/commit/28434c8f56c2caae222befb1… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-01-16 (Fri, 16 Jan 2015) Changed paths: M Polymorph-Widgets.package/Pharo3Theme.class/class/settings/newDefaultSettings.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script449.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40449.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot.package/ClassVariable.class/instance/converting/asClassVariable.st M Slot.package/SlotClassBuilder.class/instance/accessing/sharedVariables_.st A Slot.package/extension/ByteString/instance/asClassVariable.st A Slot.package/extension/Symbol/instance/asClassVariable.st Log Message: ----------- 40449 14742 Fix: Allow defining simple ClassVariales using symbols https://pharo.fogbugz.com/f/cases/14742 14712 The print-popper should have a different color than the selection in the default Pharo theme https://pharo.fogbugz.com/f/cases/14712 14515 Damaged configurations in the image https://pharo.fogbugz.com/f/cases/14515 http://files.pharo.org/image/40/40449.zip

1 0

Implementing lazy loading for expandable collections (part 2)
by Max Leske Jan. 16, 2015

Jan. 16, 2015

Hi Alex I thought the following little experiment might interest you. I was trying to find out (as per your suggestion) how big the difference would be between: - setting the array in OrderedCollection to nil and initializing it to size 10 on first access - initializing the array in OrderedCollection to size 0. Expectation: #grow will take time, ergo, using an empty array should be slower than using a preallocated array. Experiment (Pharo 1.3 on SqueakVM): [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 100000. 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 17566 [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 10000. 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 19717 [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 0. 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 17598 [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 1000. 1 to: 10000 do: [ :i | c add: i ] ] ] timeToRun 18084 Result: growing a collection is always faster (or at least nearly equally fast)! Explanation: What makes preinitialized collections so slow is the fact the the firstIndex variable will be set to the first third of the array (3333 in this case). When the last position in the array is reached, all elements are copied to the beginning of the array (2n operations). This copy operation is really slow (which can be seen from the first example with an oversized collection that does not require copying because the last position of the array is never reached). Experiment (Pharo 4 on PharoVM): (Iâm using bigger numbers here to compensate for the faster VM :) ) [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 1000000. 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:01:09.225" [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 100000. 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:00:37.653" [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 0. 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:00:40.152" [ 10000 timesRepeat: [ | c | c := OrderedCollection new: 10000. 1 to: 100000 do: [ :i | c add: i ] ] ] timeToRun "0:00:00:42.121â Result: growing a collection is easily fast enough, although minute performance gains are possible with preinitialized collections. Explanation: #makeRoomAtLast has been improved. Also: firstIndex is now set to the beginning of the array, preventing the copy operation that made the former measurements so slow. The run with the oversized collection is only so slow because it apparently takes a lot of time to assign the large array (?). Consequence of my little experiment: My initial implementation of the idea in you paper set the array in OrderedCollection to nil under the assumption that grow operations are very costly. That choice leads to many changes in methods of OrderedCollection where it is necessary to check if the array has been initialized yet. This introduces overhead and makes the code more error prone. I see now that it makes much more sense to use an empty array, the performance lost by growing ist neglectable. It is also interesting to note that there almost never seems to be a good reason to initialize an OrderedCollection with a large array. Cheers, Max

5 9

Object>>logCr ?
by Alexandre Bergel Jan. 16, 2015

Jan. 16, 2015

Hi! I like the new way to print things in the Transcript. But I am wondering, Object>>logCr self logCr: self printString why printString is used and not asString? âfooâ logCr prints âfooâ and not foo Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 2

Re: [Pharo-dev] Implementing lazy loading for expandable collections (part 2)
by Stephan Eggermont Jan. 16, 2015

Jan. 16, 2015

Eliot wrote: >About 90% of the entire time is in the string copying primitive. >Not much to be done there. Sista could speed this up by eliminating >the validation overhead of the primitive. But with our current VM technology >there's not a lot one can do given that OrderedCollection is organized as a flat stack. > This is probably a case where an ordered tree would be faster, albeit have a lot more space overhead. Switching collections backing store to a chunked representation once they grow beyond a certain threshold is probably the best thing to support larger collections. Stephan

1 0