June 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Debugger is not stable

by stepharo

Hi andrei > > Do you use a particular Wallet object? it was in one of the tests. I put a halt into the coinFor: into2: > What image are you using? Pharo5.0 Latest update: #50759 > Can you fuel out and send the stack if you get this error again? I will try to reproduce it and send it to you. Stef > > Cheers, > Andrei > > Stef > > PS: Yes I know I'm the stupider guy in the world because I > criticise the wonderful GT tools and I should not because it is > not acceptable :) > > > Le 3/6/16 Ã 22:01, Andrei Chis a Ã©crit : >> Hi Stef, >> >> Can you provide a way to load or access the entire code of your >> example? >> >> Cheers, >> Andrei >> >> On Fri, Jun 3, 2016 at 9:43 PM, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> Hi >> >> I'm debugging a simple algo for a first exercises in Pharo >> future book and I get stepToSendOrReturn >> >> DNU when using the debugger. >> :(((((((((((((((((((((((((((((((((((( >> >> You see I would really like in Pharo that we get new tools >> only when there are better than the old >> >> ones. I still could not see how GTDebugger helps me debugging >> faster my programs. >> >> Personally the fact that GT debugger can show bytecodes or >> can be extended is not in the critical path. >> >> My critical path is that I can debug Pharo programs and now I >> cannot. >> >> I also did not see any comments on the multiple complaints >> about the funky place for the buttons. >> >> So to me GTDebugger is a disappointement. >> >> Here is the kind of code I'm debugging so this is not that >> complex nor implying concurrency or whatever complex. >> >> >> coinsFor: aValue into2: accuWallet >> >> | accu | >> self halt. >> [ >> accu := accuWallet money. >> accu < aValue ] >> whileTrue: [ >> | big | >> big := self biggest. >> [ big > (aValue - accu) ] whileTrue: [ >> big := self biggestBelow: big ]. >> self removeCoin: big. >> accuWallet addCoin: big ]. >> ^ accuWallet >> >> >> Stef >> >> >> >> > >

June 4, 2016

Re: [Pharo-dev] 200000 factorial => VM crash

by stepharo

+ 10000 > Thank you very much Eliot >

June 4, 2016

Re: [Pharo-dev] VR tracking

by stepharo

Hi bob Le 2/6/16 Ã 18:10, Bob Clark a Ã©crit : > I was just thinking about integration of Pharo into modern > technologies and I've seen some of your scope & scale of graphics > work. It's been years since I did graphics but thinking about the > future because I's love Pharo to get into the gaming space. Does Pharo > support Unity3D or Unreal Engine plugins? Not out of the box. Ronie saldago is working on the version 2 of Woden. He is working on a special FFI to speed up connexion with C. He is also working on a C++ abstraction over metal, vulkan and 3d12 Now you may try to create some bindings, it would be cool. Stef > > https://www.indiegogo.com/projects/vicovr-teleport-your-body-into-virtual-r… > > > Cheers, > Bob > >

June 4, 2016

Re: [Pharo-dev] Bloc/TxText Status

by stepharo

> This morning I discussed with Doru, and Bloc goes wellâ¦ It silently went through some active development phase. good to know :( I should not have invested into bloc in fact. Stef

June 4, 2016

Re: [Pharo-dev] Pillar configuration bug ?

by Cyril Ferlicot D.

Le 03/06/2016 14:51, Esteban Lorenzano a Ã©crit : > Without the parser you canât do anything so I would expect the parser to be a core part. > But anyway, even agreeing with your PoV, if I load #(html exporter), then I have unreferenced pillar classes in the resulting image (PRDocumentItem class>>#parser has a strong referenceâ¦ and even that method should not be there according with your statement). > > but anyway, for me the important part is: what do I need to load to have the parser? there is no group âparserâ in ConfigurationOfPillar. > > cheers! > Esteban > > > Hi Esteban, I agree with Damien that we might want the Model and exporter without the parser. If the parser is missing as a group, this is a problem. The strong reference was removed already in the development version. I wall open an issue to let Yann and Thibault see the problem and correct it :) -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

June 4, 2016

Re: [Pharo-dev] Debugger is not stable

by Andrei Chis

Hi Stef, On Sat, Jun 4, 2016 at 9:08 AM, stepharo <stepharo(a)free.fr> wrote: > Hi andrei > > ThibaultDucasse/Wallet > > And remove the roundTo: 0.1 in the coinFor:into2: method. > > The while loop will iterate forever and pressing on into nearly kill you > > else you get killed by DNU from the debugger. > I loaded the code, removed #roundTo: 0.1 in #coinFor:into2:, and experimented with #testCoinsForPayingWithOtherCoins which seems to trigger the recursion but I cannot reproduce the error. Do you use a particular Wallet object? What image are you using? Can you fuel out and send the stack if you get this error again? Cheers, Andrei Stef > PS: Yes I know I'm the stupider guy in the world because I criticise the > wonderful GT tools and I should not because it is not acceptable :) > > > Le 3/6/16 Ã 22:01, Andrei Chis a Ã©crit : > > Hi Stef, > > Can you provide a way to load or access the entire code of your example? > > Cheers, > Andrei > > On Fri, Jun 3, 2016 at 9:43 PM, stepharo <stepharo(a)free.fr> wrote: > >> Hi >> >> I'm debugging a simple algo for a first exercises in Pharo future book >> and I get stepToSendOrReturn >> >> DNU when using the debugger. :(((((((((((((((((((((((((((((((((((( >> >> You see I would really like in Pharo that we get new tools only when >> there are better than the old >> >> ones. I still could not see how GTDebugger helps me debugging faster my >> programs. >> >> Personally the fact that GT debugger can show bytecodes or can be >> extended is not in the critical path. >> >> My critical path is that I can debug Pharo programs and now I cannot. >> >> I also did not see any comments on the multiple complaints about the >> funky place for the buttons. >> >> So to me GTDebugger is a disappointement. >> >> Here is the kind of code I'm debugging so this is not that complex nor >> implying concurrency or whatever complex. >> >> >> coinsFor: aValue into2: accuWallet >> >> | accu | >> self halt. >> [ >> accu := accuWallet money. >> accu < aValue ] >> whileTrue: [ >> | big | >> big := self biggest. >> [ big > (aValue - accu) ] whileTrue: [ >> big := self biggestBelow: big ]. >> self removeCoin: big. >> accuWallet addCoin: big ]. >> ^ accuWallet >> >> >> Stef >> >> >> >> > >

June 4, 2016

Re: [Pharo-dev] Pillar configuration bug ?

by Esteban Lorenzano

> On 04 Jun 2016, at 09:35, stepharo <stepharo(a)free.fr> wrote: > >>> >>> On 01 Jun 2016, at 20:44, Damien Cassou <Damien.Cassou(a)inria.fr> wrote: >>> >>> On June 1, 2016 6:31:29 PM GMT+02:00, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> Iâm installing pillar like this: >>>> >>>> pillar: spec >>>> spec project: 'Pillar' with: [ >>>> spec >>>> className: 'ConfigurationOfPillar'; >>>> loads: #('html exporter'); >>>> repository: 'http://smalltalkhub.com/mc/Pier/Pillar/main' ] >>>> >>>> who, according to me, should give me elements to parse pillar >>> I don't have the code at hand but this not what I expect : the parser is not necessary to export html, you just need a document model (which you could get through a Markdown parser for example). >> Without the parser you canât do anything so I would expect the parser to be a core part. >> But anyway, even agreeing with your PoV, if I load #(html exporter), then I have unreferenced pillar classes in the resulting image (PRDocumentItem class>>#parser has a strong referenceâ¦ and even that method should not be there according with your statement). > > Esteban this is not really true. I manupilate citezen objects and want to export them as html and I was wondering: > should I emit pillar -> parser -> model -> html or model -> html and this is what I will do. whateverâ¦ my point is that if it is not intended to be there, I should not see a strong (and undefined) reference in what I inject to the system. and my other point is that I still need a pointer to âwhat I need to load to have the parserâ. Some group like âparserâ, for example. Right now the only way I have to load it would be to load allâ¦ and thatâs not the purpose of having groups, I think (no point on having them if I need to load all anyway), so there is a problem with the configuration. Esteban >> >> but anyway, for me the important part is: what do I need to load to have the parser? there is no group âparserâ in ConfigurationOfPillar. >> >> cheers! >> Esteban >> >>> >>>> export to htmlâ¦ but when I finish, my installation is lacking a parser. >>>> >>>> â¦ and PRDocumentItem class>>#parser is having an undeclared behaviour >>>> (PRPillarParserMain is not in the system). >>> This has probably been fixed by Yann already in the development version. >>> >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Success is the ability to go from one failure to another without >>> losing enthusiasm." --Winston Churchill

June 4, 2016

Re: [Pharo-dev] Debugger is not stable

by Tudor Girba

Hi, > On Jun 4, 2016, at 9:08 AM, stepharo <stepharo(a)free.fr> wrote: > > Hi andrei > ThibaultDucasse/Wallet > > And remove the roundTo: 0.1 in the coinFor:into2: method. > The while loop will iterate forever and pressing on into nearly kill you > > else you get killed by DNU from the debugger. Thanks for the code. Now, how do I trigger the debugger problem? @Andrei: you can load the code like this: Gofer new smalltalkhubUser: 'thibautducasse' project: 'wallet'; package: 'Wallet'; load Cheers, Doru > Stef > PS: Yes I know I'm the stupider guy in the world because I criticise the wonderful GT tools and I should not because it is not acceptable :) > > Le 3/6/16 Ã 22:01, Andrei Chis a Ã©crit : >> Hi Stef, >> >> Can you provide a way to load or access the entire code of your example? >> >> Cheers, >> Andrei >> >> On Fri, Jun 3, 2016 at 9:43 PM, stepharo <stepharo(a)free.fr> wrote: >> Hi >> >> I'm debugging a simple algo for a first exercises in Pharo future book and I get stepToSendOrReturn >> >> DNU when using the debugger. :(((((((((((((((((((((((((((((((((((( >> >> You see I would really like in Pharo that we get new tools only when there are better than the old >> >> ones. I still could not see how GTDebugger helps me debugging faster my programs. >> >> Personally the fact that GT debugger can show bytecodes or can be extended is not in the critical path. >> >> My critical path is that I can debug Pharo programs and now I cannot. >> >> I also did not see any comments on the multiple complaints about the funky place for the buttons. >> >> So to me GTDebugger is a disappointement. >> >> Here is the kind of code I'm debugging so this is not that complex nor implying concurrency or whatever complex. >> >> >> coinsFor: aValue into2: accuWallet >> >> | accu | >> self halt. >> [ >> accu := accuWallet money. >> accu < aValue ] >> whileTrue: [ >> | big | >> big := self biggest. >> [ big > (aValue - accu) ] whileTrue: [ >> big := self biggestBelow: big ]. >> self removeCoin: big. >> accuWallet addCoin: big ]. >> ^ accuWallet >> >> >> Stef >> >> >> >> > -- www.tudorgirba.com www.feenk.com "What we can governs what we wish."

June 4, 2016

Re: [Pharo-dev] install GitFileTree from catalog --> missing class

by stepharo

This is why we need to have metadata of loaded packages inside the image. Because right now the maintainer of the package is forced to remove information from his configuration :( Been there with RB. Setf Le 3/6/16 Ã 13:38, Esteban Lorenzano a Ã©crit : > yes, but then GitFileTree from catalog is downloading a wrong version :) > >> On 03 Jun 2016, at 13:28, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> STON is now (in 6.0) used as JSON parser. >> >>> On 03 Jun 2016, at 13:24, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> this class is not there anymore : >>> >>> MCFileTreeJsonParser >>> >>> (Pharo 6.0 version) >> > >

June 4, 2016

Re: [Pharo-dev] Pillar configuration bug ?

by stepharo

>> On 01 Jun 2016, at 20:44, Damien Cassou <Damien.Cassou(a)inria.fr> wrote: >> >> On June 1, 2016 6:31:29 PM GMT+02:00, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> Iâm installing pillar like this: >>> >>> pillar: spec >>> spec project: 'Pillar' with: [ >>> spec >>> className: 'ConfigurationOfPillar'; >>> loads: #('html exporter'); >>> repository: 'http://smalltalkhub.com/mc/Pier/Pillar/main' ] >>> >>> who, according to me, should give me elements to parse pillar >> I don't have the code at hand but this not what I expect : the parser is not necessary to export html, you just need a document model (which you could get through a Markdown parser for example). > Without the parser you canât do anything so I would expect the parser to be a core part. > But anyway, even agreeing with your PoV, if I load #(html exporter), then I have unreferenced pillar classes in the resulting image (PRDocumentItem class>>#parser has a strong referenceâ¦ and even that method should not be there according with your statement). Esteban this is not really true. I manupilate citezen objects and want to export them as html and I was wondering: should I emit pillar -> parser -> model -> html or model -> html and this is what I will do. > > but anyway, for me the important part is: what do I need to load to have the parser? there is no group âparserâ in ConfigurationOfPillar. > > cheers! > Esteban > >> >>> export to htmlâ¦ but when I finish, my installation is lacking a parser. >>> >>> â¦ and PRDocumentItem class>>#parser is having an undeclared behaviour >>> (PRPillarParserMain is not in the system). >> This has probably been fixed by Yann already in the development version. >> >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." --Winston Churchill > >

June 4, 2016