- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Roassal Bug related to Athens?

by Usman Bhatti

So, in a meeting, Igor convinced me that surface cannot be handled at the level of framework. The reason is that the surfaces in athens created by the client applications have some application-level semantics such as extent, that cannot be known by the framework. So, application has to integrate session logic so that surface is initialized whenever image is restarted. Hence, checkSession default implementation in Athens throws an exception. For new comers like me, for creating surfaces and maintaining surfaces, this is useful to understand the session checking code : AthensFlakeDemo new openInWorld. I hope this helps others. Usman On Tue, Dec 3, 2013 at 11:21 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 3 December 2013 23:05, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > >> >> >> >> On Tue, Dec 3, 2013 at 10:35 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >> >>> >>> >>> >>> On 3 December 2013 15:21, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: >>> >>>> >>>> On Tue, Dec 3, 2013 at 2:29 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>> >>>>> >>>>> >>>>> >>>>> On 3 December 2013 14:18, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: >>>>> >>>>>> Igor, >>>>>> >>>>>> I had a look at Athens demo to understand how to manage sessions and >>>>>> surfaces because Roassal uses AthensSurface and there is a defensive >>>>>> mechanism in place in Roassal to initialize the surface in case it is not >>>>>> done. In the meantime, I have discovered that the red rectangle bug is >>>>>> present in Athens demos as well. >>>>>> >>>>>> So, to reproduce. >>>>>> AthensFlakeDemo new openInWorld >>>>>> save image >>>>>> open image >>>>>> >>>>> >>>>>> I tested in Moose 5.0. >>>>>> >>>>>> 1. Should I open a bug entry in Pharo? >>>>>> >>>>>> only if you intend to fix it. because this demo was not intended to >>>>> be 'fully featured, end-user compatible >>>>> and fool-proof demo'. it just a demo to show animation and discard it, >>>>> but if you insist this is a bug, >>>>> feel free to fix it. >>>>> >>>> >>>> Unfortunately, I wont have time for this. For me it would have been >>>> good, had Athens provided an example of session management as a good client >>>> so that example-oriented people like me could understand easily. Because, >>>> otherwise, I'll have to look at the code of NativeBoost and that adds to >>>> the level of complexity because I would do things with trial and error. >>>> >>>> >>> No need. There is one example: look at AthensSceneView >>> >>> >>>> >>>>> >>>>>> 2. With my superficial knowledge of Athens, my guess is that the >>>>>> session management can be done in Athens so that Roassal (and other tools >>>>>> built on top of Athens) do not need to do it. May be it is the case already >>>>>> but the demos are not using it then. >>>>>> >>>>>> I disagree. >>>>> >>>> Because then, files can also open/close and delete themselves >>>>> automatically, so you will be left only to do reading and writing... >>>>> Resource management is an application-level responsibility, not >>>>> framework level. >>>>> I cannot predict in Athens, how often one wants to create/destroy or >>>>> (re)use surfaces, and therefore i cannot >>>>> create and dispose them when i see fit within framework. >>>>> Correct me if i wrong. >>>>> >>>> >>>> I think this doesn't compare to file handling because there are many >>>> types of operations possible on files and that are application-specific. >>>> Here resource management is actually exception-handling: I should not give >>>> to my client a surface that does not exist any more. Now, of course, if >>>> there is some application-level intelligence is involved, we cannot put >>>> that in the framework. >>>> >>>> Surface is like file, you create it, delete it.. write to it.. >>> the management of surfaces is absolutely out of scope of framework. >>> More than that, surfaces is not something which you operate with >>> usually. Because usually its just a canvas. >>> >> >> Still, I will maintain that a minimalistic session logic should be built >> by default in Athens. Because otherwise each application has to maintain a >> session instance variable and a logic to test that session hasn't changed >> in between to keep a surface alive, which is lowest common denominator for >> all the applications using Athens. >> >> Usman, i have impression that you didn't looked at code at all. > > AthensSurface subclass: #AthensCairoSurface > uses: TCairoLibrary > instanceVariableNames: 'handle context builder id ftFontRenderer > session' > classVariableNames: '' > poolDictionaries: 'AthensCairoDefs' > category: 'Athens-Cairo' > > > what you think 'session' ivar and checkSession method does there? > You can make subclass if you want and redefine default behavior. > > But my main problem that you still don't see that the code in example(s) > is NOT the lowest common denominator for all applications using Athens. > Lowest common denominator is Athens API. > Athens API defines and describes roles (surface, canvas, paints etc) and > their protocols, but NOT how to create/initialize and manage such objects. > > > > >> regards, >> >> Usman >> >> >>> >>> But I would understand the absence of such a mechanism in the framework >>>> but then a tutorial should explain to novices/first-timers how to do it. >>>> >>>> >>> this sort of things is tiniest (but of course necessary) parts of whole >>> application, and usually will belong to some service layers built around/on >>> top of athens. >>> in future, sure thing you won't need to care about it. >>> >>> >>>> Usman >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>>> Usman >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Dec 2, 2013 at 5:14 PM, Usman Bhatti <usman.bhatti(a)gmail.com>wrote: >>>>>> >>>>>>> Hello Igor, >>>>>>> >>>>>>> Moose 5.0 is using Athens as default canvas for Roassal and we have >>>>>>> bug with Roassal that seems to be related to Athens. >>>>>>> http://code.google.com/p/moose-technology/issues/detail?id=1019 >>>>>>> >>>>>>> I think it is related to the fact that we create a surface in the OS >>>>>>> with Athens and once we quit the image, the surface is destroyed as well. >>>>>>> So, when image is restarted with the visualization trying to use the >>>>>>> surface, we get the error. >>>>>>> >>>>>>> Could you point to what possibly can be done to avoid this error? >>>>>>> Merely checking the existence of an appropriate drawing surface in Athens >>>>>>> every time visualization is drawn, would it suffice? >>>>>>> >>>>>>> regards, >>>>>>> >>>>>>> Usman >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > -- > Best regards, > Igor Stasenko. >

Dec. 5, 2013

Re: [Pharo-dev] Json case: Mapping objects to dictionaries

by Paul DeBruicker

FWIW - The ElasitcSearch stuff only maps to Dictionaries because of an oversight on my part. It should be fine if those objects materialized as JsonObjects. What are you doing to get Dictionaries? Its been a while since I looked at the code. To map domain objects I usually do something custom because I usually don't want all inst vars being sent as JSON. An example of what I normally do is: #jsonWriteOn: aStream | y | y := JsonObject new. self varNamesToSerializeAsJson. do: [ :each | (self perform: each asSymbol) isNil ifFalse: [ y at: each put: (self perform: each asSymbol) ] ]. y jsonWriteOn: aStream and then when materializing: fromJson: aJsonResult self varsToMaterializeFromJson do: [ :eachSymbol | | jsonObj class obj | jsonObj := aJsonResult at: eachSymbol asString ifAbsent: [ nil ]. jsonObj notNil ifTrue: [ class := MyDomain classForJsonVariableNamed: eachSymbol. obj := class isNil ifTrue: [ jsonObj trimBoth ] ifFalse: [ class fromJson: jsonObj ]. self perform: (eachSymbol , ':') asSymbol with: obj ] ] #classForJsonVariableNamed: just looks up in a dictionary that contains inst var names as keys and classes as values. That all being said I'd be interested to learn a better way to do it. Hope this helps Paul Norbert Hartl wrote > What would be the best software to map my objects to dictionaries? There > are a lot of packages in pharo that deal with JSON somehow. But it seems > none does mapping from objects to dictionaries and is standalone. Weâve > got > > - NeoJSON package . Maps objects to strings directly for performance > reason > - JSON package. Maps string to JsonObject (subclassed from dictionary) > - Voyage magritte based mapper: Closest to what I find useful but buried > inside of Voyage. And Iâm not sure it would be easy to factor out this > module as a standalone mapper. > - Seaside javascriptâ¦ : I forgot what it really does. I often shy away > looking at it because I donât want to suck in all the dependencies. > > Iâm asking because for me this is an important asset. If we talk about > JSON there are three things: Objects, JSON structure (being dictionaries > and other collections in pharo) and JSON strings. Writing to another > server or to a file producing JSON strings seems to be enough. But using > it for another system like MongoDB or ElasticSearch this does not work. > Here the common interface seems to be dictionaries. With ElasticSearch > mapping dictionaries to JSON and MongoDB mapping dictionaries to BSON. So > a good descriptive way to map objects to dictionaries would be a good > thing to have. > > Any thoughts? > > Norbert -- View this message in context: http://forum.world.st/Json-case-Mapping-objects-to-dictionaries-tp4727773p4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 5, 2013

Re: [Pharo-dev] Json case: Mapping objects to dictionaries

by Esteban A. Maringolo

Norbert, I'm currently building the dictionaries myself. I have a specific domain class of mapper for each "message" (JSON). The mapper builder manually builds my domain objects from the dictionary returned by "JSJsonParser parse: aString", when writing creates a Dictionary and sends #asJson to it. E.g. I have a EventBuilder which can build an Event from a JSON string or viceversa. I used NeoJSON in the beggining and it's blazing fast (because it is stream based), but I couldn't get my head around some particular cases (which I don't remember now, sorry). I WILL give another try, but with time to fully understand it. In the Java side of my app, this is one of the simplest things to deal with, manually to read and write, by using JSONObject and JSONArray, there's not more of it than this. Regards, Esteban A. Maringolo 2013/12/5 Norbert Hartl <norbert(a)hartl.name>: > What would be the best software to map my objects to dictionaries? There are a lot of packages in pharo that deal with JSON somehow. But it seems none does mapping from objects to dictionaries and is standalone. Weâve got > > - NeoJSON package . Maps objects to strings directly for performance reason > - JSON package. Maps string to JsonObject (subclassed from dictionary) > - Voyage magritte based mapper: Closest to what I find useful but buried inside of Voyage. And Iâm not sure it would be easy to factor out this module as a standalone mapper. > - Seaside javascriptâ¦ : I forgot what it really does. I often shy away looking at it because I donât want to suck in all the dependencies. > > Iâm asking because for me this is an important asset. If we talk about JSON there are three things: Objects, JSON structure (being dictionaries and other collections in pharo) and JSON strings. Writing to another server or to a file producing JSON strings seems to be enough. But using it for another system like MongoDB or ElasticSearch this does not work. Here the common interface seems to be dictionaries. With ElasticSearch mapping dictionaries to JSON and MongoDB mapping dictionaries to BSON. So a good descriptive way to map objects to dictionaries would be a good thing to have. > > Any thoughts? > > Norbert

Dec. 5, 2013

Re: [Pharo-dev] Json case: Mapping objects to dictionaries

by Chris Cunningham

I've used the SCouchDB interface - which include mapping object to dictionaries (well, JSONObjects) and mapping back from them. http://www.squeaksource.com/SCouchDB.html Of course, it is tied to CouchDB, but shouldn't be to hard to pry the mapping part out (once you find it). On Thu, Dec 5, 2013 at 7:44 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > What would be the best software to map my objects to dictionaries? There > are a lot of packages in pharo that deal with JSON somehow. But it seems > none does mapping from objects to dictionaries and is standalone. Weâve got > > - NeoJSON package . Maps objects to strings directly for performance reason > - JSON package. Maps string to JsonObject (subclassed from dictionary) > - Voyage magritte based mapper: Closest to what I find useful but buried > inside of Voyage. And Iâm not sure it would be easy to factor out this > module as a standalone mapper. > - Seaside javascriptâ¦ : I forgot what it really does. I often shy away > looking at it because I donât want to suck in all the dependencies. > > Iâm asking because for me this is an important asset. If we talk about > JSON there are three things: Objects, JSON structure (being dictionaries > and other collections in pharo) and JSON strings. Writing to another server > or to a file producing JSON strings seems to be enough. But using it for > another system like MongoDB or ElasticSearch this does not work. Here the > common interface seems to be dictionaries. With ElasticSearch mapping > dictionaries to JSON and MongoDB mapping dictionaries to BSON. So a good > descriptive way to map objects to dictionaries would be a good thing to > have. > > Any thoughts? > > Norbert >

Dec. 5, 2013

Re: [Pharo-dev] [Issue tracker] Help for reviewing needed

by btc＠openinworld.com

Dec. 5, 2013

Json case: Mapping objects to dictionaries

by Norbert Hartl

What would be the best software to map my objects to dictionaries? There are a lot of packages in pharo that deal with JSON somehow. But it seems none does mapping from objects to dictionaries and is standalone. Weâve got - NeoJSON package . Maps objects to strings directly for performance reason - JSON package. Maps string to JsonObject (subclassed from dictionary) - Voyage magritte based mapper: Closest to what I find useful but buried inside of Voyage. And Iâm not sure it would be easy to factor out this module as a standalone mapper. - Seaside javascriptâ¦ : I forgot what it really does. I often shy away looking at it because I donât want to suck in all the dependencies. Iâm asking because for me this is an important asset. If we talk about JSON there are three things: Objects, JSON structure (being dictionaries and other collections in pharo) and JSON strings. Writing to another server or to a file producing JSON strings seems to be enough. But using it for another system like MongoDB or ElasticSearch this does not work. Here the common interface seems to be dictionaries. With ElasticSearch mapping dictionaries to JSON and MongoDB mapping dictionaries to BSON. So a good descriptive way to map objects to dictionaries would be a good thing to have. Any thoughts? Norbert

Dec. 5, 2013

Re: [Pharo-dev] Using TreeModel>>selectAll

by Benjamin

your tree here is single selection so it will not work TreeModel new roots: #(1 2 3); multiSelection: true; openWithSpec; selectAll Ben On 05 Dec 2013, at 15:38, Martin Dias <tinchodias(a)gmail.com> wrote: > Hi, > > I'm not sure how this method should be used. I tried in different > ways, for example: > > TreeModel new > roots: #(1 2 3); > selectAll; > openWithSpec > > But always the items are unselected. Is it a bug? or I didn't find the > way to use it? > > Thanks, > MartÃn >

Dec. 5, 2013

Using TreeModel>>selectAll

by Martin Dias

Hi, I'm not sure how this method should be used. I tried in different ways, for example: TreeModel new roots: #(1 2 3); selectAll; openWithSpec But always the items are unselected. Is it a bug? or I didn't find the way to use it? Thanks, MartÃn

Dec. 5, 2013

[pharo-project/pharo-core]

by GitHub

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

Dec. 5, 2013

[pharo-project/pharo-core] 33795b: 30623

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 33795b495e1ba73fe3a1bb6211410786fdbfcad6 https://github.com/pharo-project/pharo-core/commit/33795b495e1ba73fe3a1bb62… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-12-05 (Thu, 05 Dec 2013) Changed paths: M Graphics-Files.package/GIFReadWriter.class/class/image reading%2Fwriting/typicalFileExtensions.st M Graphics-Primitives.package/Color.class/class/instance creation/fromString_.st R Morphic-Base.package/SystemWindow.class/instance/drawing/areasRemainingToFill_.st M Morphic-Base.package/SystemWindow.class/instance/panes/paneMorphSatisfying_.st M Multilingual-Encodings.package/Unicode.class/class/class initialization/parseCaseMappingFrom_.st M Multilingual-TextConversion.package/TextConverter.class/class/instance creation/newForEncoding_.st M Nautilus.package/NautilusMCBindings.class/instance/private/retrieveMCPackageFor_.st M NautilusRefactoring.package/ChangesBrowser.class/instance/initialization/initializePresenter.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script278.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30623.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M UIManager.package/UIManager.class/class/initialization/default.st Log Message: ----------- 30623 12346 Cleanup on some Nautilus methods https://pharo.fogbugz.com/f/cases/12346 12351 ChangesBrowser is broken https://pharo.fogbugz.com/f/cases/12351 12350 Rendering artifacts on shrinking SystemWindows https://pharo.fogbugz.com/f/cases/12350 12343 Cleanup on some UI methods https://pharo.fogbugz.com/f/cases/12343 http://files.pharo.org/image/30/30623.zip

Dec. 5, 2013