- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Fuel] Materialization error, #DoIt Not found

by Vanessa PeÃ±a Araya

On 12/06/2012 04:19 PM, Mariano Martinez Peck wrote: > > > On Thu, Dec 6, 2012 at 5:21 PM, Vanessa PeÃ±a Araya > <van.c.pena(a)gmail.com <mailto:van.c.pena@gmail.com>> wrote: > > Hi Mariano, > > It works, thank you very much! > > > Excellent. So for next version of Fuel we will fix it. You will only > need the package Fuel (not FuelMetalevel) and you will use the normal > #newDefault instead of #newDefaultWithMethodSupport. > So far, I just created the issue: > > http://code.google.com/p/fuel/issues/detail?id=172 Thank you :) For now, adding the FuelMetalevel package. > > > > Vanessa. > > > On 12/05/2012 07:13 PM, Mariano Martinez Peck wrote: >> quick answer (later with more detail): >> Install also de package: FuelMetalevel and instantiate the >> serializer this way (instead of #newDefault) >> >> FLSerializer newDefaultWithMethodSupport >> >> let me know if it works. >> >> On Wed, Dec 5, 2012 at 10:40 PM, Vanessa PeÃ±a Araya >> <van.c.pena(a)gmail.com <mailto:van.c.pena@gmail.com>> wrote: >> >> Hi, >> >> I was working with Fuel to save and load a Roassal view >> (serialize and materialize), and everything works perfect (so >> far) except for one thing: if I have an Anouncer which its >> registry has an announcementSubscription with a nil >> subscriber, it does not work is gives me this error: >> >> >> >> Standard Roassal interactions are OK, but if I do: >> >> aRoElement on: ROMouseClick do: [something] in a Wokspace >> materialization does not work. If I execute the same code in >> a method send as message to an object I have not this error >> and materialization works perfectly. This means I can not >> save some visualizations created in the Workspace. >> >> Have anyone experience something like this? >> >> Thanks, >> Vanessa. >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 7, 2012

Re: [Pharo-project] Pharo 2.0 BETA, Configs and Seaside

by Igor Stasenko

On 6 December 2012 22:34, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > Do people only use the ConfigurationBrowser for initial installing of the > packages, or does it get used for when the package is updated? If the > former, this makes a lot of sense; if the later, you might want to rethink > removing it. Since integration, the updates will be automatically handled by pharo team. so you just need to click 'update' button. Using non-stable, non-blessed, bleeding-edge version of config is another story :) -- Best regards, Igor Stasenko.

Dec. 7, 2012

Re: [Pharo-project] [ANN] Pharo 2.0 enters BETA

by Igor Stasenko

On 6 December 2012 20:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Great. > > We will release Moose 4.7 on top of Pharo 1.4 soon (probably next week or so), and afterwards we will immediately switch to Pharo 2.0. > you won't regret that. 2.0 is really cool ! (even though i am still stuck with a bit outdated image.. :) > Cheers, > Doru > > > On 6 Dec 2012, at 18:10, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> Hi, >> >> Today I finished the pending integrations for move to Pharo 2.0. >> There is still a problem with the VMs (for NB), but that's not a stopper for moving on. >> >> What does this means? >> Starting now, no new changes of API will be allowed, just bug fixes and minor enhancements that does not change the system behavior. >> We still have a long stabilization path until we can release, but we hope a couple of months will put us in shape :) >> >> Esteban > > -- > www.tudorgirba.com > > "Presenting is storytelling." > > -- Best regards, Igor Stasenko.

Dec. 7, 2012

[Pharo-project] [NativeBoost] New kid on the block: NBExternalTypeArray + future plans

by Igor Stasenko

Hi there, i just uploaded new version of config - 1.8 (development), where i introduced the new public core classs: NBExternalTypeArray. The class provides a generic functionality for working with arrays which elements is of foreign (C) type. And since it is a subclass of ArrayedCollection, you can use them naturally as any other Array(s)/Collection(s) in smalltalk. Here the class comment: -------------- I am abstract class which provides a convenient interface to work with arrays which elements are values of some external (C) type. In order to use me with concrete element type, you must create a subclass of me and initialize element type properly. Subclassing using public subclass: - if you want to create a public subclass of me, then you should make sure that in class-side #initialize method, you add self-send #initElementType: and specify the element type name to use. (And of course, initialize the class before attempting to create any instances). Subclassing with anonymous subclass: To create an anonymous subclass of me, use #ofType: protocol, i.e.: floatArrayClass := NBExternalTypeArray ofType: 'float'. Please note that separate #at: / #at:put: methods will be automatically added in each and every subclass. Never remove them, despite they looking identical to superclass methods! !!CAUTION!! Currently those methods do not perform any range checking for index. So, please make sure you using sane index values (1<= index <= size). Also, note, that class instance variables: elementType and elementSize, once initialized, is considered read-only. Changing them, once you created at least a single instance of your class may lead to funny consequences. Arrays in external memory vs object memory: My instances can work either with data held in object memory or in external memory. The difference is only at instantiation time: To create a new array in object memory, just use #new: protocol: myArray := floatArrayClass new: 10. "create a new array with 10 floats". To allocate a new array in external memory, use #externalNew: protocol: myArray := floatArrayClass externalNew: 10. .. myArray free. "and sure thing, do not forget to free external memory after use". To check whether array uses object memory or external memory , use #isExternal protocol. Also, you can convert any external address into NBExternalTypeArray subclass instance, i.e. suppose some external function returns a pointer (instance of NBExternalAddress): pointer := self callSomeFunc: 1. So, in order to access memory at given address as array of 100 elements of type 'int', you can use following: myArray := (NBExternalTypeArray ofType: 'int') onAddress: pointer size: 100. myArray at: 1. "read first element" myArray at: 2 put: 50. "write second element" myArray do: [:each | ... ] ... etc (sure thing, in the above example, the "NBExternalTypeArray ofType: 'int' " expression is just to demonstrate the intent. It should be replaced with some variable, which you initialize only once and use many times, because creating an anonymous subclass each time would be highly ineffective ) Supported protocols: Since NBExternalTypeArray inherits from ArrayedCollection, you're free to use any protocols defined there as well as in its superclasses. There's only few additions comparing to ArrayedCollection, like #isExternal and #free . Copying: a #copy behavior is special for external arrays: A copy will always use object memory, even if original used external memory. ----------------- Now, i would really appreciate if someone could do some more serious testing (how well it works as Collection etc), and of course do a review and feedback :) My nearest plans concerning NB: - review the callbacks interface (to make it more convenient to use , as we discussed on this list some time ago) - by seeing how nicely NBExternalTypeArray deals with external/internal duality, i am now inclined to do the same for NBExternalStructure. (Yes.. nice and simple things are not often so obvious :) Like that, NBExternalStructure will be just a regular class (instead of var-byte one) which will keep 'data' object which is ByteArray for object memory allocated struct, and NBExternalAddress for indirect reference to structure data somewhere beyond our safe harbor ;)) - also, if time allows, i'd like to get threaded calls working. The prototype was started by Javier almost a year ago, and we need to finish it. Also, we want to work together with Esteban for making Objective-C bridge functional. This will bring us one step closer to multiple different goals: - native window management - allow us to avoid extra blitting Athens -> Display -> ObjC view.. but just Athens ->Obj-C :) - direct use of Obj-C runtime - .. reimplement VM features in image + adding new stuff (and sure thing, Esteban has own) And, of course, besides of that, soon we will start working on unified FFI interface for Pharo. So, people will no longer need to choose between old FFI/Alien/NB, since it will be ONE in the core functionality of a system. P.S. i'd like to thank everyone, who helping me with development of NB. In last couple months, i really see how your contribution helps bringing NB to better quality levels. Even though, not all of you risking to practice dark-assembly magic, ditching some nuances and polishing rough corners etc is really helpful.. because i wouldn't say that i'm in a mood of polishing project right now, because i more focused on adding missing features. :) -- Best regards, Igor Stasenko.

Dec. 7, 2012

Re: [Pharo-project] Pharo 2.0 BETA, Configs and Seaside

by Paul DeBruicker

Torsten Bergmann wrote > 3. I would like to see a config with a recent Seaside for Pharo 2.0 > showing up and putting it into ConfigurationBrowser too so Seaside is > easily loadable right from Pharo 2.0. > > It loads well on the BETA when one uses: > > > https://github.com/renggli/builder/blob/master/scripts/seaside31-pharo2.st > > and > > Gofer new > squeaksource: 'ZincHTTPComponents'; > "package: 'Zinc-HTTP';" > package: 'Zinc-Seaside'; > load. > > > The only thing I've hit was some deprecation stuff > #includesSubString: vs. includesSubstring: > but I did not check all seaside tests. > > @Dale: whats the state of a Seaside config for Pharo 2.0? > > Thanks > T. I think the Seaside configs in this issue should work in Pharo 2, for both Seaside 3.0.7 and 3.1 (which is not released) but I'm not positive and plan to spend some time raising my confidence this weekend. http://code.google.com/p/seaside/issues/detail?id=748 -- View this message in context: http://forum.world.st/Pharo-2-0-BETA-Configs-and-Seaside-tp4658383p4658401.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 7, 2012

Re: [Pharo-project] Pharo 2.0 BETA, Configs and Seaside

by Chris Cunningham

On Thu, Dec 6, 2012 at 2:32 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> 1. Since NativeBoost is now integrated I removed the config > >> from the ConfigurationBrowser - because it makes no > >> sense to install when it is already in the image :) > >> > >... > >Do people only use the ConfigurationBrowser for initial installing of the > >packages, or does it get used for when the package is updated? If the > >former, this makes a lot of sense; if the later, you might want to rethink > >removing it. > > When there is a newer NB version we will either integrate it into > the base image or put the config (with a higher version declared > as stable) in again so this newer version can be loaded easily > from the tool. > > So, removing it from the browser is basically removing it from the repository? Then if a new one shows up (and is appropriate for Pharo 2.0) you'd add it to the repository again? That makes sense. And should have been obvious if I had read and thought about your first email a bit longer. -Chris

Dec. 6, 2012

[Pharo-project] Pharo 2.0 BETA, Configs and Seaside

by Torsten Bergmann

>> 1. Since NativeBoost is now integrated I removed the config >> from the ConfigurationBrowser - because it makes no >> sense to install when it is already in the image :) >> >... >Do people only use the ConfigurationBrowser for initial installing of the >packages, or does it get used for when the package is updated? If the >former, this makes a lot of sense; if the later, you might want to rethink >removing it. When there is a newer NB version we will either integrate it into the base image or put the config (with a higher version declared as stable) in again so this newer version can be loaded easily from the tool. Bye T.

Dec. 6, 2012

Re: [Pharo-project] Pharo 2.0 BETA, Configs and Seaside

by Chris Cunningham

On Thu, Dec 6, 2012 at 1:16 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > 1. Since NativeBoost is now integrated I removed the config > from the ConfigurationBrowser - because it makes no > sense to install when it is already in the image :) > ... Do people only use the ConfigurationBrowser for initial installing of the packages, or does it get used for when the package is updated? If the former, this makes a lot of sense; if the later, you might want to rethink removing it. -Chris

Dec. 6, 2012

Re: [Pharo-project] [ANN] Pharo 2.0 enters BETA

by StÃ©phane Ducasse

On Dec 6, 2012, at 8:37 PM, Tudor Girba wrote: > Great. > > We will release Moose 4.7 on top of Pharo 1.4 soon (probably next week or so), and afterwards we will immediately switch to Pharo 2.0. Doru I will try sunday to concentrate and see if I can understand the bug in metacello I got. > > Cheers, > Doru > > > On 6 Dec 2012, at 18:10, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> Hi, >> >> Today I finished the pending integrations for move to Pharo 2.0. >> There is still a problem with the VMs (for NB), but that's not a stopper for moving on. >> >> What does this means? >> Starting now, no new changes of API will be allowed, just bug fixes and minor enhancements that does not change the system behavior. >> We still have a long stabilization path until we can release, but we hope a couple of months will put us in shape :) >> >> Esteban > > -- > www.tudorgirba.com > > "Presenting is storytelling." > >

Dec. 6, 2012

[Pharo-project] Pharo 2.0 BETA, Configs and Seaside

by Torsten Bergmann

1. Since NativeBoost is now integrated I removed the config from the ConfigurationBrowser - because it makes no sense to install when it is already in the image :) 2. Please help to test external packages and if they are known to work on Pharo 2.0 please put a copy of ConfigurationOf... also into https://ss3.gemstone.com/ss/MetaRepoForPharo20.html Do not forget to put a symbolic version for #stable into the metacello config. This way they will show up in and will be loadable from the ConfigurationBrowser. 3. I would like to see a config with a recent Seaside for Pharo 2.0 showing up and putting it into ConfigurationBrowser too so Seaside is easily loadable right from Pharo 2.0. It loads well on the BETA when one uses: https://github.com/renggli/builder/blob/master/scripts/seaside31-pharo2.st and Gofer new squeaksource: 'ZincHTTPComponents'; "package: 'Zinc-HTTP';" package: 'Zinc-Seaside'; load. The only thing I've hit was some deprecation stuff #includesSubString: vs. includesSubstring: but I did not check all seaside tests. @Dale: whats the state of a Seaside config for Pharo 2.0? Thanks T.

Dec. 6, 2012