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

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by Miguel Enrique CobÃ¡ Martinez

> > The link is: > https://gforge.inria.fr/frs/download.php/25397/Pharo1.0-10508-rc2dev10.01.2… > Just a minor thing. Shouldn't the name be: Pharo-1.0-10508-rc2dev10.01.2.zip in order to match the PharoCore name format: PharoCore-1.0-10508-rc2.zip Format: (Pharo|PharoCore)-version-update-tag Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 23, 2010

Re: [Pharo-project] [ANN 1.0] Pre-cuilt CoreRC2 (#10508)

by Miguel Enrique CobÃ¡ Martinez

El vie, 22-01-2010 a las 13:12 +0100, Marcus Denker escribiÃ³: > http://gforge.inria.fr/frs/download.php/25366/PharoCore-1.0-10508rc2.zip > Magnifique! Just one little thing, isn't the name format going to be tokens separated by "-" PharoCore-1.0-10508rc2.zip -> PharoCore-1.0-10508-rc2.zip Cheers > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 23, 2010

Re: [Pharo-project] about imageSegments

by Igor Stasenko

2010/1/23 Eliot Miranda <eliot.miranda(a)gmail.com>: > > So for me image segments are too low-level and constraining. Right. Every time we wanting to say 'let VM do it for us' , we should always consider implementing it in smalltalk. For reasons you described before. My own rule of thumb: - do not put 'clever' code into VM. VM should be dumb, leaving cleverness to language level. -- Best regards, Igor Stasenko AKA sig.

Jan. 23, 2010

[Pharo-project] PluggableButtonMorph>>askBeforeChanging

by Igor Stasenko

As to me this is a good example of placing a decisive role into wrong place, bloating the morph's protocol. The 'askBeforeChanging' is used in #performAction which asks the model , if it wants to change: askBeforeChanging ifTrue: [model okToChange ifFalse: [^ self]]. But why doing that, isn't model unable to send #okToChange in its own action handling method? i.e. if button does: model perform: actionSelector where actionSelector == #foo, what prevents a model to implement this method as: foo self okToChange ifFalse: [ ^ self]. self doSomething. ? Or, even if model wants to do something without asking in one case, but with asking in another, what prevents it to implement: #doSomething and #doSomethingIfOkToDoIt and choose appropriate selector as action to a button(s)? Or, if we look at it from different angle. A button widget main role is to trigger some action. The action could be anything: from very simple one up to complex, composite one. And 'ask-before-change-then-do' is an example of composite action. So, let button just trigger that composite action. Why putting an action handling logic to the place where action having completely abstract meaning? -- Best regards, Igor Stasenko AKA sig.

Jan. 23, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by Alexandre Bergel

Thanks Mariano for this image. I like the background. Am I the only one to prefer rounded windows instead of straight corners? Cheers, Alexandre On 22 Jan 2010, at 11:32, Mariano Martinez Peck wrote: > Hi folks. This is 1.0 RC2. Please, look at this image in a nice way > because it is very likely that if there is no big issue, it will be > 1.0 official. We need to release 1.0. > > Issues fixed: In addition to the fixes from the PharoCore, we have: > 1033, 1182, 1826, 1862. > > Big changes: > > - Now we use OB from Lukas Renggli repository and we have ALL TESTS > GREEN!!! Thanks Lukas! > - O2 loads again in the image without breaking OB. Read the > workspace to see how to install it. Thanks David and Alexandre! > - We have almost (only one failing here) ALL TESTS of the PharoDev > image in green. They are more than 8800. > > Smaller changes: > > - Fixed the problem with Metacello and OCompletion. No more overrides. > - System -> About now shows the real Pharo name, not the core. I am > also being "compatible" with the new SystemVersion that we have in > 1.1 :) Thanks Michael and Miguel! > - I didn't left again my proxy settings. I fixed this in my build > scripts. It should be clean :) > - Mercury bar is back again. If you want to disable: Preferences > disable: #mercuryPanel. > - Added a lot of cleanups after creating the image, including > condensing .changes > - Added Refactoring-Spelling again. Thanks Stan! > - I wrote a ConfigurationOfNile instead of Nile-All and depends on > Monticello dependencies. > - New welcome workspaces. Also getting started workspace and another > workspace explaining how to load external packages like Seaside (2.8 > and 3), Magritte, Pier, Moose, GetTools, O2, etc. Finally it is also > added a link to the new ProfStef :) > Do you think that with this we are able to close issue1479 ? > - Background with Pharo picture. This was a joke. It looked > nice :) I promise I don't put it again if you don't like. To > remove it evaluate: > World color: Color white. > - Enable the preference fastDragWindowForMorphic. Sorry, but it most > computers this works REALLY slow. If you want them back, just > disable it. > - When installing Seaside now doesn't ask for user and password > ( admin/seaside ). In addition, the Seaside Control Panel is only > isntalled if OB is installed. This means that yu can install it in > core or dev. Thanks Dale! > - Disable of System Update for Dev images as it is not working > properly. > > > The link is: https://gforge.inria.fr/frs/download.php/25397/Pharo1.0-10508-rc2dev10.01.2… > > Cheers > > Mariano > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 23, 2010

Re: [Pharo-project] about imageSegments

by Eliot Miranda

On Fri, Jan 22, 2010 at 5:51 PM, Martin McClure <martin(a)hand2mouse.com>wrote: > Eliot Miranda wrote: > > > > Parcels are wonderful things, but my impression is that ImageSegment > and > > parcels are designed to do rather different things. Parcels are used > for > > physical delivery of packages (primarily code), whereas ImageSegments > > are for arbitrary graphs of objects (primarily not code, although > some > > folks have tried to use ImageSegments for code). If parcels are > designed > > to be more general than package delivery, I'd like to hear about it. > > > > > > You're talking abut parcels expression in VW not their underlying > > nature. Parcels' underlying nature is just efficient unpacking of > > object graphs. The code stuff is layered above that, so much so that it > > obscures the essentials. Parcels are at core another pickling format, > > but one that is very much faster than standard approaches. My > > comparisons of BOSS (VW's Binary Object Storage System, very similar to > > ReferenceStream et al) and Parcels showed parcels to be 4 times faster > > than BOSS. > > > > Basically you get out of a parcel what you put in, and in VW parcels get > > code put in them. But you can put arbitrary objects in parcels. Note > > that parts of the parcel marshalling code is used in Opentalk. > > Thanks, that's good to know. > > > > > I suspect that the only VM support that ImageSegments really need are > > the mark-sweep primitives to discover what objects are in the > > ImageSegment. All other algorithms, file format, etc. can (and maybe > > should) be redesigned to be better, but using the GC to find the > objects > > is the heart of what ImageSegment is. > > > > > > The core problem is that an image segment is a raw binary snapshot of a > > part of the heap, so a particular VMs object header formats and tagging > > scheme is built-in to the segment. If I were to evolve the Squeak > > garbage collector and object representation to make Cog significantly > > faster, as I fully intend to do this year, image segments will at least > > break backward compatibility. They can only be exchanged between VMs > > running exactly the same object representation. Parcels can be loaded > > into very different systems; VW loads parcels into either 32-bit or > > 64-bit images without difficulty, and parcels written before > > immutability or ephemerons were added could be loaded after. > > > > So for me image segments are too low-level and constraining. > > Really? Look at Interpreter>>primitiveLoadImageSegment and Interpreter>>primitiveStoreImageSegment in VMMaker. Wow. I haven't looked at the binary format; I had assumed from > what little code I'd read that it was more machine-independent than > that. And the format should be defined at the Smalltalk level, not in > the VM. But, again, to me the defining quality of ImageSegment isn't > what format is used, it's what you can do with it, especially how you > define what objects are in the ImageSegment. > Right! cheers Eliot > > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 23, 2010

Re: [Pharo-project] about imageSegments

by Martin McClure

Eliot Miranda wrote: > > Parcels are wonderful things, but my impression is that ImageSegment and > parcels are designed to do rather different things. Parcels are used for > physical delivery of packages (primarily code), whereas ImageSegments > are for arbitrary graphs of objects (primarily not code, although some > folks have tried to use ImageSegments for code). If parcels are designed > to be more general than package delivery, I'd like to hear about it. > > > You're talking abut parcels expression in VW not their underlying > nature. Parcels' underlying nature is just efficient unpacking of > object graphs. The code stuff is layered above that, so much so that it > obscures the essentials. Parcels are at core another pickling format, > but one that is very much faster than standard approaches. My > comparisons of BOSS (VW's Binary Object Storage System, very similar to > ReferenceStream et al) and Parcels showed parcels to be 4 times faster > than BOSS. > > Basically you get out of a parcel what you put in, and in VW parcels get > code put in them. But you can put arbitrary objects in parcels. Note > that parts of the parcel marshalling code is used in Opentalk. Thanks, that's good to know. > > I suspect that the only VM support that ImageSegments really need are > the mark-sweep primitives to discover what objects are in the > ImageSegment. All other algorithms, file format, etc. can (and maybe > should) be redesigned to be better, but using the GC to find the objects > is the heart of what ImageSegment is. > > > The core problem is that an image segment is a raw binary snapshot of a > part of the heap, so a particular VMs object header formats and tagging > scheme is built-in to the segment. If I were to evolve the Squeak > garbage collector and object representation to make Cog significantly > faster, as I fully intend to do this year, image segments will at least > break backward compatibility. They can only be exchanged between VMs > running exactly the same object representation. Parcels can be loaded > into very different systems; VW loads parcels into either 32-bit or > 64-bit images without difficulty, and parcels written before > immutability or ephemerons were added could be loaded after. > > So for me image segments are too low-level and constraining. Really? Wow. I haven't looked at the binary format; I had assumed from what little code I'd read that it was more machine-independent than that. And the format should be defined at the Smalltalk level, not in the VM. But, again, to me the defining quality of ImageSegment isn't what format is used, it's what you can do with it, especially how you define what objects are in the ImageSegment. Regards, -Martin

Jan. 23, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by Gary Chambers

On Fri, 2010-01-22 at 17:11 +0100, Torsten Bergmann wrote: > Things I've noticed: > > - Code completion is working for me > - the intro workspace window should be smaller > - the intro workspace window should provide colors as the other two > workspaces (maybe we can group them in a window with tree like help system) > - maybe the background should be stretched according to window size (Gary?) A few ways of doing this, all require new code though. Perhaps I'll refactor AlphaImageMorph to migrate most of its capabilities to ImageFillStyle. Would be nicer than alternative of subclassing FullscreenMorph, embedding a locked AlphaImageMorph and a few tweaked methods before adding to the World, though would need a modification to #extent: of PasteUpMorph to take account of the fillstyle's needs (like it possibly should anyway for gradients, for example). Regards, Gary > - the class categories in the browser are not ordered alphabetic > - I hate the old style Squeak cursor and would rather see different > cursors (see ConfigurationOfVistaCursors for an example) > - anything looks professional - except the old squeak icons, any > designer around > - I was not able to compile Java and C# code with it ;) > > Have fun > T.

Jan. 23, 2010

Re: [Pharo-project] Input different data types (integers or datetimes) in a textbox.

by Gary Chambers

Something like the following example could work, though there are a few rough edges at present in terms of caret position and editing (I've only used the treansform bit to change case of strings, for instance, which behaves reasonably)... (UITheme builder newAutoAcceptTextEntryFor: ValueHolder new inspect getText: #contents setText: #contents: getEnabled: nil help: nil) converter: ((ObjectTransformedStringConverter forClass: Integer) transformBlock: [:s | s select: [:c | c isDigit]]); openInWindow Dates are a bit trickier since the class-side #readFrom: expects a correct format or will error... Regards, Gary. On Fri, 2010-01-22 at 12:28 -0800, nullPointer wrote: > I want know if exists some way or mechanism for input data in a widget of a > specific type. For example a textbox with only numbers ( decimals or only > integers ) or some mechanism of mask edit for fill a text in a textbox of > "type" DateTime ?? > > IÂ´m developing a grid widget and I need in each column define a type of > data. With strings is easy but for another values i donÂ´t know do it. > > As always excuse me for my poor english, and regards. > -- > View this message in context: http://n2.nabble.com/Input-different-data-types-integers-or-datetimes-in-a-… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 23, 2010

Re: [Pharo-project] about imageSegments

by Eliot Miranda

On Fri, Jan 22, 2010 at 4:33 PM, Martin McClure <martin(a)hand2mouse.com>wrote: > Eliot Miranda wrote: > > > > > > On Fri, Jan 22, 2010 at 12:35 PM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: > > > > hi guys > > > > the more I read about imageSegments the more I would like to remove > > them (or to package them > > carefully - not sure that this is possible) and may be add a new > > class to > > just have one simple way of invoking the save (but not swapping back > in) > > > > I think that mariano diving into them is a great phd exercise but on > > the long run > > I see it as a brittle mechanism. > > > > what do you think? > > > > > > David Leibs' work on parcels in VW demonstrated that high-performance > > packaging can be done with no VM support. > > Parcels are wonderful things, but my impression is that ImageSegment and > parcels are designed to do rather different things. Parcels are used for > physical delivery of packages (primarily code), whereas ImageSegments > are for arbitrary graphs of objects (primarily not code, although some > folks have tried to use ImageSegments for code). If parcels are designed > to be more general than package delivery, I'd like to hear about it. > You're talking abut parcels expression in VW not their underlying nature. Parcels' underlying nature is just efficient unpacking of object graphs. The code stuff is layered above that, so much so that it obscures the essentials. Parcels are at core another pickling format, but one that is very much faster than standard approaches. My comparisons of BOSS (VW's Binary Object Storage System, very similar to ReferenceStream et al) and Parcels showed parcels to be 4 times faster than BOSS. Basically you get out of a parcel what you put in, and in VW parcels get code put in them. But you can put arbitrary objects in parcels. Note that parts of the parcel marshalling code is used in Opentalk. I suspect that the only VM support that ImageSegments really need are > the mark-sweep primitives to discover what objects are in the > ImageSegment. All other algorithms, file format, etc. can (and maybe > should) be redesigned to be better, but using the GC to find the objects > is the heart of what ImageSegment is. > The core problem is that an image segment is a raw binary snapshot of a part of the heap, so a particular VMs object header formats and tagging scheme is built-in to the segment. If I were to evolve the Squeak garbage collector and object representation to make Cog significantly faster, as I fully intend to do this year, image segments will at least break backward compatibility. They can only be exchanged between VMs running exactly the same object representation. Parcels can be loaded into very different systems; VW loads parcels into either 32-bit or 64-bit images without difficulty, and parcels written before immutability or ephemerons were added could be loaded after. So for me image segments are too low-level and constraining. > > > > When you implement a binary > > format, carefully designed for unpacking performance, at the image level > > you get the freedom to add flexibility. I added shape change support to > > parcels (and some higher level features that aren't relevant here) after > > David had left. So I think the right approach is to reimplement image > > segments entirely in the image without special VM support and add > > metadata to the format (class shape information) and you'll probably end > > up with something that is nearly as performant but much more flexible > > and evolvable. > > > > > > The two keys to the performance of David's design are the separation of > > objects from their references and the btching of object allocations. A > > parcel file starts with a number of allocations of well-known classes > > (e.g. this parcel contains 17 large integers of the following sizes, and > > 3 floats, and 17 symbols of the following sizes etc) followed by an > > arbitrary number of "N instances of class X". So the unpacker populates > > an object table with indices from 1 to N where N is the number of > > objects in the parcel, but it does so in batch, spinning in a loop > > creating N instances of each class in turn, instead of determining which > > object to create as it walks a (flattened) input graph. After the > > instance data comes the reference data, which slots refer to which > > objects. Again the unpacker can spin filling in slots from the > > reference data instead of determining whether to instantiate an object > > or dereference an object id as it walks the input graph. So loading is > > much faster than e.g. ReferenceStream-style approaches. > > I like that approach for a file format. It probably doesn't even make > writing the file out much slower; the work has to be done in multiple > passes, but each pass is simpler. And write speed is important: A parcel > is typically written once and loaded many times, but one common pattern > of ImageSegment use is write once, load once, discard, or even write > once, load never. > Right. Writing out needs to be fast, but IIRC image segments aren't written incrementally; writing happens after a full walk of the graph has been made. So all we're talking about is adding a sort phase that assigns object table ids in the graph which shouldn't be expensive. > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 23, 2010