December 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Convert to Athens

by J.F. Rick

I've updated to the latest of Athens and I still get this bug, except now the square appears at 0@1. Cheers, Jeff On Wed, Dec 4, 2013 at 6:35 PM, J.F. Rick <self(a)je77.com> wrote: > Here's a piece of code to demonstrate the problem: > > AthensWrapMorph new > extent: 300@300; > addMorph: (Morph new > position: 100@100; > extent: 100@100; > yourself); > openInWorld. > > I think this should draw a blue square at 100@100. Instead, it draws a > blue square at 0@0. What am I doing wrong? > > Cheers, > > Jeff > > > > On Wed, Dec 4, 2013 at 6:17 PM, J.F. Rick <self(a)je77.com> wrote: > >> I'm facing some problems with AthensWrapMorph. Basically, when I add a >> morph, I can't change its position. It just stays in the top left. Whatever >> I try to do to change its position (self position: 100@100) does not >> work. >> >> Cheers, >> >> Jeff >> >> >> On Wed, Nov 20, 2013 at 5:04 PM, J.F. Rick <self(a)je77.com> wrote: >> >>> Thanks. It works. I already have found a few bugs and one thing I don't >>> understand. >>> >>> (1) A few Paint things seem to implement athensFillRectangle:on: and >>> athensFillPath:on: rather than fillRectangle:on: and fillPath:on:. It seems >>> like it should be the latter rather than the former. I changed the names >>> and the evil rectangle of doom disappeared. >>> >>> (2) Using the AthenWrapMorph, it seems that the bottom row of pixels is >>> not rendered or clipped. I can stop this phenomenon by changing the >>> createSurface method to have the extent be 0@1 bigger. While that >>> works, it seems like there's a bug somewhere in AthensCairoSurface. >>> >>> (3) I ended up changing a morph so that it should render differently. In >>> standard Pharo, I just use "self changed" and it updates. Is there an >>> equivalent in Athens? Do I have to explicitly tell Athens to rerender it? >>> If so, how? I tried "self render" but that did not seem to help. >>> >>> Cheers, >>> >>> Jeff >>> >>> >>> On Wed, Nov 20, 2013 at 11:08 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>> >>>> http://www.smalltalkhub.com/#!/~Pharo/Athens >>>> >>>> >>>> On 20 November 2013 09:04, J.F. Rick <self(a)je77.com> wrote: >>>> >>>>> Right. Where is this Athens repository? I have the latest in >>>>> Pharo30/main (Athens-Morphic-MarcusDenker.23.mcz) and that does not seem to >>>>> include AthensWrapperMorph. >>>>> >>>>> Cheers, >>>>> >>>>> Jeff >>>>> >>>>> >>>>> On Wed, Nov 20, 2013 at 8:35 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 19 November 2013 17:42, J.F. Rick <self(a)je77.com> wrote: >>>>>> >>>>>>> Indeed. I would like to know that. It doesn't seem to be included in >>>>>>> the latest Pharo 3.0. >>>>>>> >>>>>>> >>>>>> it could be not yet included. >>>>>> in that case, load most recent Athens-Morphic package from athens >>>>>> repository. >>>>>> >>>>>> >>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Jeff >>>>>>> >>>>>>> >>>>>>> On Fri, Nov 15, 2013 at 7:34 PM, Hilaire Fernandes < >>>>>>> hilaire.fernandes(a)gmail.com> wrote: >>>>>>> >>>>>>>> Le 15/11/2013 14:17, Igor Stasenko a Ã©crit : >>>>>>>> > >>>>>>>> > for transition , i implemented a special morph, AthensWrapMorph >>>>>>>> > which wraps (as its name says) its children morphs and forces >>>>>>>> them to be >>>>>>>> > rendered by athens >>>>>>>> > (the child morphs will never receive #drawOn: but >>>>>>>> #drawOnAthensCanvas: >>>>>>>> > instead ). >>>>>>>> >>>>>>>> >>>>>>>> I guess Jeff, may want to know where to find this wrapper. >>>>>>>> >>>>>>>> Hilaire >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dr. Geo http://drgeo.eu >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Jochen "Jeff" Rick, Ph.D. >>>>>>> http://www.je77.com/ >>>>>>> Skype ID: jochenrick >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Jochen "Jeff" Rick, Ph.D. >>>>> http://www.je77.com/ >>>>> Skype ID: jochenrick >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >>> -- >>> Jochen "Jeff" Rick, Ph.D. >>> http://www.je77.com/ >>> Skype ID: jochenrick >>> >> >> >> >> -- >> Jochen "Jeff" Rick, Ph.D. >> http://www.je77.com/ >> Skype ID: jochenrick >> > > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

Dec. 5, 2013

Re: [Pharo-dev] [ANN] Roassal 3d

by Torsten Bergmann

> > 3. Providing a script is so "old style" and hard to remember - why not define a #stable > > and put your config into MetaRepoForPharo30 > > So others can easily load it via ConfigurationBrowser with a few clicks in a fresh image. > > Yes! Youâre very right. Can you add me as a contributor to MetaRepoForPharo30 ? I need this to commit right? I added you, but I think you can also commit without since this is in group Pharo, so I think anyone who contributes to Pharo is able to contribute to the meta repo for configs bye T.

Dec. 4, 2013

Re: [Pharo-dev] Opal hook?

by ClÃ©ment BÃ©ra

2013/12/4 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > I forgot to add that the OCUndeclaredVariableWarning was already handled > at semantic analysis. > This is not the case. The OCUndeclaredVariableWarning is handled in the default action. Therefore anyone can catch it. In this case for instance: [ OpalCompiler new evaluate: 'AnUnknownClass subclass: #Adaptor1Example instanceVariableNames: ''customers accountID address name phoneNumber'' classVariableNames: '''' poolDictionaries: '''' category: ''Examples-Cookbook''' ] on: OCSemanticWarning do: [ :e | e halt ] The Semantic warning is caught outside of the semantic analysis and it works perfectly fine. The only thing is that you need to retry the error and not resume it to restart the semantic analysis (or you have an inconsistent execution state in the semantic analysis visitor). > Do you suggest that default behavior should be to handle and retry instead > of handle and return? > One way to achieve what you are asking would be to initialize the > Undeclared entry to some kind of ProtoObject that does not understand > anything and rethrow a OCUndeclaredVariableWarning instead of a > MessageNotUnderstood... (very uneasy to debug, since the Debugger itself is > querying the receiver etc... - unless Debugger is using basic mirror > primitives) > > > 2013/12/4 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > >> Steph, each time you want to evaluate something, do you agree that this >> involves >> - a parse phase of the expression you want to evaluate to create an AST >> - a code generation phase from AST -> bytecodes to generate a >> CompiledMethod >> - the evaluation phase itself which evaluates above CompiledMethod with >> appropriate receiver (nil generally) >> >> I didn't check OPAL, but do you agree that the semantic analysis >> determining which are those variables you called {'AnUnknownClass'. >> 'OCUndeclaredVariableWarning'. 'self'} and how to bind them, must happen >> somewhere between AST and CompiledMethod creation? >> >> So if there is a semantic exception, like UndeclaredVariable, how would >> the CompiledMethod be generated in the first place? >> If it's not generated, how would it be executed? >> If it's not executed, how would the message on:do: be sent to a block >> with 2 arguments? >> >> Unless you suggest to attempt executing a ParseTree which is known to be >> defectuous... >> >> 2013/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >>> 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: * >>> >>> >>> I do not understand why if an exception is raised why I cannot trap it. >>> >>> [AnUnknownClass subclass: #Adaptor1Example >>> instanceVariableNames: 'customers accountID address name >>> phoneNumber' >>> classVariableNames: '' >>> poolDictionaries: '' >>> category: 'Examples-Cookbook'] on: OCUndeclaredVariableWarning >>> do: [ self halt.] does not halt. >>> >>> The fact that is is at compilation time does not mean anything to me. So >>> why? I'm totally confused by this bad and unexpected behavior. >>> Do you imply that the warning is already trapped and that I cannot take >>> precedence? Probably but this has nothing to do with compilation time. >>> >>> Then to me OCSemanticWarning should be enhanced so that we do not get >>> these silly menus. An exception should work and clients should be able to >>> customise >>> it to (for example introduce menu and dialog with the users but they >>> should not be the only default. >>> We see again this plague of interactive environment not being rethought >>> in the 2013 age. >>> >>> defaultAction >>> self errorNotification ifFalse: [ ^nil ]. >>> ^self openMenuIn: >>> [:labels :lines :caption | >>> UIManager default chooseFrom: labels lines: lines title: caption] >>> >>> but that we could specify the action to be executed instead. >>> >>> >>> to me CompilerException should have nothing to do with UI and popup. >>> Then we should be able to pass objects that knows how to handle >>> the errors in interactive way or not. >>> >>> As a clear example, this is just bad that each time we want to change >>> the UI message we have to change the compiler exception. >>> ugly at wish. >>> >>> I have no cycle to fix that now. I will check if I can get something in >>> UndefinedObject so that I can continue to work on my task. >>> >>> Stef >>> >>> >>> >>> [ 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. >>> >>> >>> >> >

Dec. 4, 2013

Re: [Pharo-dev] [ANN] Roassal 3d

by Alexandre Bergel

>> 3. Providing a script is so "old style" and hard to remember - why not define a #stable >> and put your config into MetaRepoForPharo30 >> So others can easily load it via ConfigurationBrowser with a few clicks in a fresh image. > > even better: have a jerkins build where people can download an imageâ¦ That would be great. How to do this? Cheers, Alexandre

Dec. 4, 2013

Re: [Pharo-dev] [ANN] Roassal 3d

by Alexandre Bergel

Hi! > first: this is a cool project! > > Then a few comments: > > 1. When using the script in a fresh Pharo3.0 Latest update: #30620 it complains: > > This package depends on the following classes: > ROAthensMorph > You must resolve these dependencies before you will be able to load these definitions: > R3MorphOverlay > clear This should now be fixed. Sorry about that > 2. If I use the samples from the tutorial PDF and copy them into a Pharo > workspace they are not accepted by Pharo - looks like an encoding issue in the PDF > (when copying from Adobe PDF viewer on Windows into Pharo) > > When I type the samples manually they work Yes, this is a problem from the dropbox pdf viewer. If you download the .pdf you can copy and paste without problem. > 3. Providing a script is so "old style" and hard to remember - why not define a #stable > and put your config into MetaRepoForPharo30 > So others can easily load it via ConfigurationBrowser with a few clicks in a fresh image. Yes! Youâre very right. Can you add me as a contributor to MetaRepoForPharo30 ? I need this to commit right? > 4. Did I already told you that this is a cool project? > > 5. See 4. :-) Cheers, Alexandre

Dec. 4, 2013

Re: [Pharo-dev] Opal hook?

by Nicolas Cellier

I forgot to add that the OCUndeclaredVariableWarning was already handled at semantic analysis. Do you suggest that default behavior should be to handle and retry instead of handle and return? One way to achieve what you are asking would be to initialize the Undeclared entry to some kind of ProtoObject that does not understand anything and rethrow a OCUndeclaredVariableWarning instead of a MessageNotUnderstood... (very uneasy to debug, since the Debugger itself is querying the receiver etc... - unless Debugger is using basic mirror primitives) 2013/12/4 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Steph, each time you want to evaluate something, do you agree that this > involves > - a parse phase of the expression you want to evaluate to create an AST > - a code generation phase from AST -> bytecodes to generate a > CompiledMethod > - the evaluation phase itself which evaluates above CompiledMethod with > appropriate receiver (nil generally) > > I didn't check OPAL, but do you agree that the semantic analysis > determining which are those variables you called {'AnUnknownClass'. > 'OCUndeclaredVariableWarning'. 'self'} and how to bind them, must happen > somewhere between AST and CompiledMethod creation? > > So if there is a semantic exception, like UndeclaredVariable, how would > the CompiledMethod be generated in the first place? > If it's not generated, how would it be executed? > If it's not executed, how would the message on:do: be sent to a block with > 2 arguments? > > Unless you suggest to attempt executing a ParseTree which is known to be > defectuous... > > 2013/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> 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: * >> >> >> I do not understand why if an exception is raised why I cannot trap it. >> >> [AnUnknownClass subclass: #Adaptor1Example >> instanceVariableNames: 'customers accountID address name >> phoneNumber' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Examples-Cookbook'] on: OCUndeclaredVariableWarning >> do: [ self halt.] does not halt. >> >> The fact that is is at compilation time does not mean anything to me. So >> why? I'm totally confused by this bad and unexpected behavior. >> Do you imply that the warning is already trapped and that I cannot take >> precedence? Probably but this has nothing to do with compilation time. >> >> Then to me OCSemanticWarning should be enhanced so that we do not get >> these silly menus. An exception should work and clients should be able to >> customise >> it to (for example introduce menu and dialog with the users but they >> should not be the only default. >> We see again this plague of interactive environment not being rethought >> in the 2013 age. >> >> defaultAction >> self errorNotification ifFalse: [ ^nil ]. >> ^self openMenuIn: >> [:labels :lines :caption | >> UIManager default chooseFrom: labels lines: lines title: caption] >> >> but that we could specify the action to be executed instead. >> >> >> to me CompilerException should have nothing to do with UI and popup. Then >> we should be able to pass objects that knows how to handle >> the errors in interactive way or not. >> >> As a clear example, this is just bad that each time we want to change the >> UI message we have to change the compiler exception. >> ugly at wish. >> >> I have no cycle to fix that now. I will check if I can get something in >> UndefinedObject so that I can continue to work on my task. >> >> Stef >> >> >> >> [ 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. >> >> >> >

Dec. 4, 2013

Re: [Pharo-dev] [ANN] Roassal 3d

by Alexandre Bergel

Hi Stephan! > Nice! Thanks! > When loading the configuration as shown in the manual, there was a complaint about > a class not found yet. Sorry about that. An incorrect version contained in a baseline went through our tests. The problem is now fixed. > The examples showed up fine though. They look great. Thanks! > The first one with the square/cube I couldnât get the camera viewpoint > to move to where I could see it was a cube. That worked much better with the later examples. > The session management isnât working out well: saving the image with an open view and quitting, > the image crashed on restart. Yes! Next week I will be in Lille, I hope to fix this > Iâm looking forward to adding some 3D views to PetitDelphi. That would be truly amazing! Cheers, Alexandre

Dec. 4, 2013

Re: [Pharo-dev] Opal hook?

by Nicolas Cellier

Steph, each time you want to evaluate something, do you agree that this involves - a parse phase of the expression you want to evaluate to create an AST - a code generation phase from AST -> bytecodes to generate a CompiledMethod - the evaluation phase itself which evaluates above CompiledMethod with appropriate receiver (nil generally) I didn't check OPAL, but do you agree that the semantic analysis determining which are those variables you called {'AnUnknownClass'. 'OCUndeclaredVariableWarning'. 'self'} and how to bind them, must happen somewhere between AST and CompiledMethod creation? So if there is a semantic exception, like UndeclaredVariable, how would the CompiledMethod be generated in the first place? If it's not generated, how would it be executed? If it's not executed, how would the message on:do: be sent to a block with 2 arguments? Unless you suggest to attempt executing a ParseTree which is known to be defectuous... 2013/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > 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: * > > > I do not understand why if an exception is raised why I cannot trap it. > > [AnUnknownClass subclass: #Adaptor1Example > instanceVariableNames: 'customers accountID address name > phoneNumber' > classVariableNames: '' > poolDictionaries: '' > category: 'Examples-Cookbook'] on: OCUndeclaredVariableWarning do: > [ self halt.] does not halt. > > The fact that is is at compilation time does not mean anything to me. So > why? I'm totally confused by this bad and unexpected behavior. > Do you imply that the warning is already trapped and that I cannot take > precedence? Probably but this has nothing to do with compilation time. > > Then to me OCSemanticWarning should be enhanced so that we do not get > these silly menus. An exception should work and clients should be able to > customise > it to (for example introduce menu and dialog with the users but they > should not be the only default. > We see again this plague of interactive environment not being rethought in > the 2013 age. > > defaultAction > self errorNotification ifFalse: [ ^nil ]. > ^self openMenuIn: > [:labels :lines :caption | > UIManager default chooseFrom: labels lines: lines title: caption] > > but that we could specify the action to be executed instead. > > > to me CompilerException should have nothing to do with UI and popup. Then > we should be able to pass objects that knows how to handle > the errors in interactive way or not. > > As a clear example, this is just bad that each time we want to change the > UI message we have to change the compiler exception. > ugly at wish. > > I have no cycle to fix that now. I will check if I can get something in > UndefinedObject so that I can continue to work on my task. > > Stef > > > > [ 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. > > >

Dec. 4, 2013

Re: [Pharo-dev] Opal hook?

by ClÃ©ment Bera

It didn't halt on your machine because you didn't copy and paste the code that halts (i guess I wrote too much code in the mail so it was not clear). You copied the code that I explicitly said that doesn't halt because the error is raised at compilation time. This code halts (copy, paste and run it you will see): [ OpalCompiler new evaluate: 'AnUnknownClass subclass: #Adaptor1Example instanceVariableNames: ''customers accountID address name phoneNumber'' classVariableNames: '''' poolDictionaries: '''' category: ''Examples-Cookbook''' ] on: OCSemanticWarning do: [ :e | e halt ] We can discuss this another day when you have time because seemingly my mail was not clear (you said you couldn't trap the semantic warning). Now I'm really sick today so we can discuss friday or next week. 2013/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > >> Ok I will check something on UndefinedObject to start with. > >> Then it would be fun to prototype a kind of strategy hiearchy on the > side (extracted from also) behavior of OCSemanticsError > >> It was nice to see it and since now I'm ok to have a look at the > compiler code it was interesting. > >> > > > > The current design is motivated mostly by backward compatibility, not > anything else. > > I see :) > I would really to see an headless, interactive and scriptable scenarios to > be exercised. So this is good it will get better :) > Stef >

Dec. 4, 2013

Re: [Pharo-dev] Komitter

by Benjamin

On 04 Dec 2013, at 20:12, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Does Kommitter enables partial commits (cherry picking) for a package? > If so, my question is how does it deal with MC ancestry? > > Imagine I have a package- A.247 from my-trunk. > I merge some A.312 from my-work repository with work in progress. > Now I want to cherry pick the changes which are OK, and publish only those to my-trunk. > I do so in my-trunk/A.313. > Will A.312 be in the ancestry of A.313? > Logically as MC is working, yes, because it is in the ancestry of in-image working copy. > > What if I later download A.313 from my-trunk in a fresh image and try to merge A.312 to finish the work in progress? > IMO, this is not possible, A312 being an ancestor, no change will happen. This is indeed what is happening. A solution would be to allow to merge with an ancestor. After some investigation, itâs doable. The âproblemâ is I do not know how to detect that a version has been âfully-merged" already or not. But with the patch is juste made, you can merge with your ancestors. Another approach would be the git one. When you merge, you commit automatically the merge. Ben > > So, it sounds like when I committed my-trunk/A.313 with partial changes, I should have commited my-work/A.314 immediately after with the rest of pending changes... > If I forgot to do so and threw my image away, from a fresh image, it is still possible to load A.312, merge A.313, and publish A.314 in my-work repo. > > But then it rather complicates the flow... If we commit/merge carelessly, we might throw away some valuable work in progress. > The fear of such scenario prevented us to integrate a change from Bert in Squeak/trunk enabling such partial commits (directly from MC UI in Squeak case). > > > 2013/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > +1 > > > Thanks once more for your effort. This is a really important tool for me. > > > > Uko > > > > >

Dec. 4, 2013