- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Roassal 3d now support textures

by StÃ©phane Ducasse

On Dec 3, 2013, at 10:07 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 3 December 2013 12:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > did you move some functionality (to the place they belong) to NBOpenGL? > Because this should be done and JB has already spent time on that. > > I am not sure it is good choice to expand NBOpenGL. > There's just API, and most of code is generated (imported from specs), > so changing something there makes little sense. > Accompanying package , however , would be much better (in same repo, if you want). I was talking about shadder code Stef > > > > Stef > >> hi! >> >> Just to keep you up to date with the Roassal 3d effort. >> https://www.facebook.com/photo.php?fbid=547995685287033&set=a.5299979037534… >> >> Cheers, >> Alexandre >> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> > > > > > -- > Best regards, > Igor Stasenko.

Dec. 3, 2013

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

by Igor Stasenko

On 3 December 2013 15:58, kilon alios <kilon.alios(a)gmail.com> wrote: > you dont have to wait for my example as i said checkSession is already the > example > > checkSession > session == Smalltalk session ifFalse: [ > "just reset the surface" > surface := nil. > session := Smalltalk session. > ] > > as you can see here essentially we compare session if they differ then we > know we need to reinitialize all our external resources in this example > surface . Not that it assigns surfaces as nil but you will need to fully > reinitialize the surface cause otherwise you will have a non existent > surface still. In this class a nill surface is reinitialized by another > method. > Right. Another reason why Athens has nothing to do with it: if i don't want my surfaces to live longer than single session, the way to handle that will be completely different than in given example. > Also I like to note here that Roassal Easel appear also not to check > sessions and exhibits the known problem if image is stored with Easel open. > Its something Roassal people would need to look at. > > > On Tue, Dec 3, 2013 at 4:51 PM, Usman Bhatti <usman.bhatti(a)gmail.com>wrote: > >> >> >> >> On Tue, Dec 3, 2013 at 3:46 PM, kilon alios <kilon.alios(a)gmail.com>wrote: >> >>> You are correct but so is Igor. Managing external resources has to do >>> with VM and Nativeboost itself and not with Athens. This could happen with >>> any other library. >>> >>> Session aware code is actually very easy to do and its explained >>> Athens-Tutorial package in AthensViewMorph>>checkSession . Its just 2 lines >>> of code. >>> >>> In step2 method there is a relevant comment >>> >>> "IMPORTANT NOTE: >>> the surface which we will create at this step will be used in later >>> steps. >>> This means that if you resize the window (changing the view size), you >>> may need to recreate surface. >>> Also, since surface uses external resources, quitting an image and >>> restarting it, will also require to >>> create a new surface, because the one from previous session will be no >>> longer accessible. >>> " >>> >> >> Ok. Tx. That's very useful info. I'll have a look. >> >> >>> >>> but there is no mention to check the checkSession method for an example >>> how sessions can be handled. I think this deserves a separate step by >>> itself with a nice example. Igor you want me to give me commit rights to >>> Athens repo to add that myself ? >>> >> >> And if you add the example to Athens, please let me know. >> >> >>> >>> >>> On Tue, Dec 3, 2013 at 4:21 PM, 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. >>>> >>>> >>>>> >>>>> >>>>>> 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. >>>> >>>> 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. >>>> >>>> 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.

Dec. 3, 2013

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

by Igor Stasenko

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. 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.

Dec. 3, 2013

Re: [Pharo-dev] Roassal 3d now support textures

by Igor Stasenko

On 3 December 2013 12:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > did you move some functionality (to the place they belong) to NBOpenGL? > Because this should be done and JB has already spent time on that. > > I am not sure it is good choice to expand NBOpenGL. There's just API, and most of code is generated (imported from specs), so changing something there makes little sense. Accompanying package , however , would be much better (in same repo, if you want). > Stef > > hi! > > Just to keep you up to date with the Roassal 3d effort. > > https://www.facebook.com/photo.php?fbid=547995685287033&set=a.5299979037534… > > Cheers, > Alexandre > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- Best regards, Igor Stasenko.

Dec. 3, 2013

vm patch for issue-11293

by Nicolai Hess

Hi, can someone take a look at issue 11293? There are actually two causes. One on the image side. My solution is to catch DirectoryDoesNotExist in FileList, but maybe there is a better solution. (Don't try to access unreadable directories?). The other one is on the vm-side. This vm uses a windows function (GetFileAttributesEx) that does not work properly for some special windows files (c:\pagefile.sys). My question is, where to put this patch? I attached it to this issue. But there are different squeak/pharo/cog vm sources and I don't know which one uses this function. regards Nicolai

Dec. 3, 2013

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

by StÃ©phane Ducasse

> you dont have to wait for my example as i said checkSession is already the example > > checkSession > session == Smalltalk session ifFalse: [ > "just reset the surface" > surface := nil. > session := Smalltalk session. > ] > > as you can see here essentially we compare session if they differ then we know we need to reinitialize all our external resources in this example surface . Not that it assigns surfaces as nil but you will need to fully reinitialize the surface cause otherwise you will have a non existent surface still. In this class a nill surface is reinitialized by another method. > > Also I like to note here that Roassal Easel appear also not to check sessions and exhibits the known problem if image is stored with Easel open. Its something Roassal people would need to look at. Yes I do not understand why this is not already in Roassal. Stef

Dec. 3, 2013

Re: [Pharo-dev] Opal hook?

by StÃ©phane Ducasse

thanks for your analysis I will have a look at it. I was thinking to check if I should redefine UndefinedObject>>subclass: to raise an error Stef On Dec 3, 2013, at 3:17 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > do you know if the OCUndeclaredVariable is raised for unknown superclass? > > this code: > > AnUnknownClass subclass: #Adaptor1Example > instanceVariableNames: 'customers accountID address name phoneNumber' > classVariableNames: '' > poolDictionaries: '' > category: 'Examples-Cookbook' > > is run as a Do It. In Do It, unknown variables (as here AnUnknownClass) raise an OCUndeclaredVariableWarning. > For example, running: > > AnUnknownClass subclass: #Adaptor1Example > instanceVariableNames: 'customers accountID address name phoneNumber' > classVariableNames: '' > poolDictionaries: '' > category: 'Examples-Cookbook' > > executes the default action for OCUndeclaredVariableWarning, which is opening a pop-up titled: "Unknown variable ...". Here the error is raised at compilation time, therefore it would have no effect to wrap this with a #on:do: > > [ AnUnknownClass subclass: #Adaptor1Example > instanceVariableNames: 'customers accountID address name phoneNumber' > classVariableNames: '' > poolDictionaries: '' > category: 'Examples-Cookbook' ] on: OCSemanticWarning do: [ ] > > ==> same problem. > > Now if you do: > > [ OpalCompiler new evaluate: 'AnUnknownClass subclass: #Adaptor1Example > instanceVariableNames: ''customers accountID address name phoneNumber'' > classVariableNames: '''' > poolDictionaries: '''' > category: ''Examples-Cookbook''' ] on: OCSemanticWarning do: [ :e | e halt ] > > Here we catch the error, and you can handle it. > Now it is not easily possible to resume the error, because you want a global instead and Opal expects a temp (there are way to resume but with very deep stack manipulation that I do not want to show to young pharoers present on this mailing list). So the best is to retry it. One solution is therefore: > > [ OpalCompiler new evaluate: 'AnUnknownClass subclass: #Adaptor1Example > instanceVariableNames: ''customers accountID address phoneNumber'' > classVariableNames: '''' > poolDictionaries: '''' > category: ''Examples-Cookbook''' ] > on: OCSemanticWarning do: [ :e | > Smalltalk at: e node name put: StubRootClass. > e retry ] > > with e node name answering #AnUnknownClass here. > Now you need to make sure that the exception block is executed for the case of a missing superclass and not something else or you will end up creating loads of globals. > > The exception block should be something similar to: > > [ :e | > e node name first isUppercase and: [ "some condition" ] ifTrue: [ > Smalltalk at: e node name put: StubRootClass. > ^ e retry ]. > e pass ] > > How to undefined and OCUndeclaredVariableWarning relate? > > In your case, while loading from Monticello the code is compiled and evaluated in non interactive mode. Therefore it cannot trigger the default action of OCUndeclaredVariableWarning which is a UI event. So it sets by default the unknown global to: > > Undeclared at: varName asSymbol put: nil. > OCUndeclaredVariable new name: varName asSymbol > > in: OCUndeclaredVariableWarning >>defaultAction > > which then later triggers the code in UndefinedObject. > > > > 2013/12/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Dec 3, 2013, at 11:20 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> Then for your project replace ProtoObject by StubRootClass in UndefinedObject>>subclass:instanceVariableNames:classVariableNames:poolDictionaries:category: it will work. > > yes but this is ugly because I do not want override. > So I will introduce an exception so that we can do that in a clean way. > > >> An alternative is to catch OCSemanticWarning or its subclass OCUndeclaredVariableWarning while loading the new classes and execute another code instead of the default action in the exception handling block > > > do you know if the OCUndeclaredVariable is raised for unknown superclass? > How to undefined and OCUndeclaredVariableWarning relate? > > Stef >> >> >> 2013/12/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> > Well if the class does not exists it calls the method on UndefinedObject (UndeclaredBinding). And you have: >> >> I will check and see if I can set up a hook because having classes subclasses of protoobject is not a good idea >> when loading broken code. >> >> > UndefinedObject>>subclass: nameOfClass >> > instanceVariableNames: instVarNames >> > classVariableNames: classVarNames >> > poolDictionaries: poolDictnames >> > category: category >> > "Calling this method is now considered an accident. If you really want to create a class with a nil superclass, then create the class and then set the superclass using #superclass:" >> > self traceCr: ('Attempt to create ', nameOfClass, ' as a subclass of nil. Possibly a class is being loaded before its superclass.'). >> > ^ProtoObject >> > subclass: nameOfClass >> > instanceVariableNames: instVarNames >> > classVariableNames: classVarNames >> > poolDictionaries: poolDictnames >> > category: category >> > >> > The best is to set manually the superclass after with #superclass: >> >> No because I have no idea what are the classes whose superclasses are not in the image. >> With a proper hook I could just say >> if the superclass is unknow please use the "StubRootClass" of my framework. >> else let the system handles it. >> >> Stef >> > >

Dec. 3, 2013

Re: [Pharo-dev] [Pharo-users] Building Pharo using Interpreter Class

by StÃ©phane Ducasse

Hello kirstin why dimitri is not able to post? can you tell us more? Stef On Dec 3, 2013, at 1:17 PM, Kirstin Heidler <kirstin.heidler(a)student.hpi.uni-potsdam.de> wrote: > My freind Dimitri was not able to post his message. I am working with him on this. > > _______________________________________________________________________________ > > Hello, > > as part of a Seminar in the University im trying to build the PharoVM. > According to the README file here ([1]) I was able to generate and to > build the VM successfully. > > Now I would like to build the VM without Cog or Stack-to-Register > optimizations... The problem here is, that I could not find any config > class (which is a subclass of CPlatformConfig), that provides the right > configurations and allows to build the VM without errors. I have tried > to modify PharoUnixConfig(because it was the default config class), but > unfortunately the build failes when the compiler tries to compile > gcc3x-interp.c. > > Could somebody help me with this problem? How should I configure my own > Config class? > > Basically our Group tries to implement an object table in Pharo and we > want to use (and modify) the basic Interpreter class. > > > > [1] https://github.com/pharo-project/pharo-vm > > > Best regards, > Dimitri Korsch >

Dec. 3, 2013

Re: [Pharo-dev] CompiledMethod>>#= is broken

by Eliot Miranda

On Tue, Dec 3, 2013 at 11:27 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Tue, Dec 3, 2013 at 9:49 AM, Oscar Nierstrasz < > oscar.nierstrasz(a)gmail.com> wrote: > >> >> The following code breaks: >> >> (SortedCollectionTest>>#testDo) = (SortedCollectionTest>>#testStoreOn). >> >> because it makes use of AdditionalMethodState>>#analogousCodeTo: which >> tries to send #analogousCodeTo: to a property which is an Association. >> >> It seems to me the solution is to implement >> Association>>#analogousCodeTo: with an equality test: >> >> analogousCodeTo: anObject >> ^self class == anObject class >> and: [ self = anObject ] >> >> Does this make sense? >> > > Yes. I should have written it this way in the first place. Thanks. > > >> >> See: >> >> >> https://pharo.fogbugz.com/f/cases/12077/MNU-in-AdditionalMethodState-analog… >> >> Oscar Nierstrasz >> >> >> > > > -- > best, > Eliot > -- best, Eliot

Dec. 3, 2013

Re: [Pharo-dev] Unifying Testing Ideas

by Attila Magyar

Sean P. DeNigris wrote > In fact, #does: and #answers: could easily be merged, using double > dispatch to pass either a block or a value. It's true, but it would make difficult to return a block. E.g. mock can receive: #msg; answers: [ [..] ] Sean P. DeNigris wrote > Unrelatedly, it would be slightly clearer to rename "anything" to > "anyMessage". "anything" makes it seem like it could be passed as an > argument, which doesn't work. Or alternately, you could probably rename > AnyMessage to Anything and combine its API with that of AnyArgument if > they don't clash... I agree, I'll try to combine them first, but anyMessage/anyArgument seems fine too. Anyways, I'm working on the next version with a slightly different api. My plan is to fully separate the DSL from the main part. This will make possible to play with different syntax without touching the core. Or even the users will be able to define their own syntax. -- View this message in context: http://forum.world.st/Unifying-Testing-Ideas-tp4726787p4727144.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 3, 2013