Re: [Pharo-dev] [pharo-project/pharo-core] d2bfc7: 60040

[Tudor Girba]

Great. Congratulations!

Doru


> On May 27, 2016, at 12:43 PM, Esteban Lorenzano  wrote:
> 
> so yes, we finally did it :)
> 
> Esteban
> 
>> On 27 May 2016, at 12:27, GitHub  wrote:
>> 
>>  60040
>> 14605 Integrate Epicea
>>  https://pharo.fogbugz.com/f/cases/14605
> 

--
www.tudorgirba.com
www.feenk.com

"Presenting is storytelling."

[Pharo-dev] got some bugs in Pharo 50

[stepharo]

Just to report (I did not have the time to check in 60a) but I got red 
square of death with komitter.


I also got

NECTypedModel>>initializeSelectorsFor: aClass
|excludedClasses|
selectors reset.
excludedClasses := (expanded ifTrue: [#()] ifFalse: [Object 
withAllSuperclasses]).

selectors addAll: ((aClass allSelectorsWithout: excludedClasses)

collect: [:each | NECSelectorEntry contents: 
each type: #selector])




DNU on allSelectorsWithout:


with such code


mostCommonlyUsedSelectors
"self mostCommonlyUsedSelectors"

| result |
result := Bag new.
environment cla

^ cursor here

do: [ :each | result addAll: each selectors].
^ result sortedCounts


Stef

Re: [Pharo-dev] Debugger is not stable

[Denis Kudriashov]

Hi.

2016-06-04 18:01 GMT+02:00 stepharo :

>   I got it now
> GTInspector does not open on latest stack frame but the one before and
> if I scroll I get it
>

Yes. And step into not autoscroll stack view.
I like GTDebugger. It is step forward for our tools. Now only real issue
for me is horribly slow stepping. I guess each "step over" action refreshes
all inspector views.
I hope proposed solution for fast inspector updating could address it.

Re: [Pharo-dev] Debugger is not stable

[Tudor Girba]

Hi,

We certainly want to have a bullet proof debugger.

However, by looking at the selector you mention, the problem you got with the 
crashing debugger is almost surely reproducible with the old debugger. It is 
unlikely related to the GT Debugger (which is essentially a UI).

The issue you mention with the stack selection is a GT Debugger issue indeed. 
@Andrei: let us open an issue for this and let us look again at the selection 
strategy for the SUnit debugger.

Cheers,
Doru


> On Jun 4, 2016, at 6:01 PM, stepharo  wrote:
> 
>> 
>> I will try to reproduce it and send it to you. 
> 
> I tried and after several tries I could not reproduce the bug but I could 
> totally freeze 
> the image :(
> Do not ask me how. See screenshot below
> 
> 
> Now I do not get it but when I put a halt like the following
> 
> 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 
> 
> - sometimes I cannot get it stopped there :( when running the test for 
> coinsFor: 
> testCoinsForPayingWithOtherCoins for example. 
> 
> I got it now 
> GTInspector does not open on latest stack frame but the one before and if 
> I scroll I get it 
> 
> 
> So this one should be easy to fix. For the other one I do not know. 
> 
> 
> Having a robust debugger would be priority number one. 
> 
> Stef
> 
> 
> Stef

--
www.tudorgirba.com
www.feenk.com

"It's not what we do that matters most, it's how we do it."

Re: [Pharo-dev] Spotter suggestions

[Tudor Girba]

Hi,

I promised to get back to this one. I know it’s late, but I somehow did not 
manage until now. I apologize.

There is a bit of discrepancy between what happens during the development of GT 
and what is being communicated. One of the feelings that seem to come through 
is that the feedback is not taken into account. We think this is not quite so.

As an exemplification, here is an overview of what happened as a result of this 
long thread:
- the preview triangle in spotter is more prominent and it gets highlighted on 
hover
- Selectors are now called Messages
- there are shortcuts available for special categories like References, 
Implementors or Senders
- when only one search category is available, the results are expanded in place
- help was added with a shortcuts overview (this is just a step)
- scrolling was improved.
- you get buttons available on mouse over a category or an item

I hope this helps a bit.

Cheers,
Doru



> On Jan 20, 2016, at 10:39 AM, David Allouche  wrote:
> 
> Since you asked to keep challenging…
> 
> Preamble: Sorry, I did one of those long messages again. I hope I am not 
> annoying people with that.
> 
>> On 19 Jan 2016, at 22:40, Tudor Girba  wrote:
>> 
>> Hi,
>> 
>>> On Jan 19, 2016, at 9:18 PM, stepharo  wrote:
>>> 
>>> 
>>> 
>>> Le 19/1/16 20:25, David Allouche a écrit :
 BTW, thanks for the explanations for Spotter.
>> 
>> You are welcome. Please keep challenging. This is how good design happens.
>> 
>> 
> On 19 Jan 2016, at 18:37, Tudor Girba  wrote:
> 
> And then, in Spotter we have another discovery mechanism: Shift. When you 
> press it, all clickable things get highlighted (including the arrow). We 
> chose Shift because it is something that you type often as part of a 
> text, so it will be very likely that you will press it when working with 
> Spotter as well. And this will get you to see that something happens.
 I am lazy and fearful of RSI. If I can avoid using the shift key at all, I 
 am quite happy. So I did not notice that the arrows where clickable.
>>> 
>>> :)
>>> Same here.
>> 
>> What is RSI?
>> 
>> Most people I know use Shift to type an upper case, and we observed that 
>> when people search, they often tend to still use uppercase. Not all, but 
>> many. That is why we put this functionality on Shift. This does not mean 
>> that it is enough, but we just wanted to increase the chance of people 
>> stumbling across this without any documentation. It only partially succeeded.
> 
> You already stated your reasoning, and I understand it. I was just making 
> noise for people like Stef and me, who never use Shift unless they HAVE TO.
>> Anyway, we should externalize the key bindings. Another thing on the to do 
>> list :)
> 
> Sure, great!
> 
> 
 Here are a few suggestions that would fit my workflow.
 
 I also think that "Selectors" should appear after classes and before 
 packages, and be called "Messages". Typically I want to open a specific 
 class, or a specific message in a specific class.
>> 
>> #Messages is not a bad name, but then again I also thought that #Selectors 
>> was explicit enough :). What do others think?
> 
> Any interest in putting "Messages" after "Classes" and before "Packages”?
> Another advantage of "Messages" is that "#m" is unambiguous. Currently, "#se" 
> is ambiguous (#senders and #selectors), that is a serious annoyance.

 The short list of implementors at the top level is usually noise and might 
 have confused Stef. It becomes relevant once the message is fully 
 specified.
 
 Diving in should be done with right arrow when at the end of the command 
 line.
 Diving out with left arrow at the start of the command line.
>>> I was wondering what is the benefit to have cmd - shit arrow vs arrow
>> 
>> Left/Right is used to move inside the text area (there is only one text 
>> field in the whole UI), and that is why you cannot consistently use it for 
>> navigating through results.
>> 
>> Navigating when the cursor is at the end is a tempting idea, but it implies 
>> a mode that is not contextual (you need to things to look at). That is why I 
>> would not want to have it in this interface.
> 
> Not overloading unmodified right/left arrows sounds like an obvious good idea.
> 
> But as you already mentioned, Spotter is a special context, so one needs to 
> take a step back to evaluate the interaction possibilities.
> 
> Typically, in the Spotter command line, I never use left-right arrows, and I 
> think this is common. If people mistype something, and have immediate 
> feedback, they tend to use backspace to fix it, instead of in-line editing.
> 
> Spotter is also very similar to a class browser like Nautilus, where 
> left-right arrows are the primary way to dive in and out of packages, 
> classes, protocols, methods. That makes right and left arrows intuitive 

[Pharo-dev] the impact of moldability

[Tudor Girba]

Hi,

There were a couple of emails in the recent period that questioned the 
usefulness of moldability (the ability of developers to customize their tools 
deeply and inexpensively). More specifically, the question was about the 
moldability of the GTDebugger.

I put together a couple of thoughts of why we think that moldability is 
actually a competitive advantage:
http://www.humane-assessment.com/blog/the-impact-of-moldability/

Please read it and provide feedback.

Cheers,
Doru

--
www.tudorgirba.com
www.feenk.com

"Reasonable is what we are accustomed with."

Re: [Pharo-dev] Debugger is not stable

[Tudor Girba]

Hi,

I tried several times to reproduce this and could not. If you could get an 
image with the problem it would be the best case scenario.

Cheers,
Doru


> On Jun 4, 2016, at 5:39 PM, stepharo  wrote:
> 
> 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  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

"To lead is not to demand things, it is to make them happen."

Re: [Pharo-dev] Debugger is not stable

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

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

[stepharo]

+ 1


Thank you very much Eliot

Re: [Pharo-dev] VR tracking

[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-reality#/ 



Cheers,
Bob

Re: [Pharo-dev] Bloc/TxText Status

[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

Re: [Pharo-dev] Pillar configuration bug ?

[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



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] Debugger is not stable

[Andrei Chis]

Hi Stef,

On Sat, Jun 4, 2016 at 9:08 AM, stepharo  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  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
>>
>>
>>
>>
>
>

Re: [Pharo-dev] Pillar configuration bug ?

[Esteban Lorenzano]

> On 04 Jun 2016, at 09:35, stepharo  wrote:
> 
>>> 
>>> On 01 Jun 2016, at 20:44, Damien Cassou  wrote:
>>> 
>>> On June 1, 2016 6:31:29 PM GMT+02:00, Esteban Lorenzano 
>>>  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

Re: [Pharo-dev] Debugger is not stable

[Tudor Girba]

Hi,


> On Jun 4, 2016, at 9:08 AM, stepharo  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  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."

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

[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  wrote:

STON is now (in 6.0) used as JSON parser.


On 03 Jun 2016, at 13:24, Esteban Lorenzano  wrote:

this class is not there anymore :

MCFileTreeJsonParser

(Pharo 6.0 version)

Re: [Pharo-dev] Pillar configuration bug ?

[stepharo]

On 01 Jun 2016, at 20:44, Damien Cassou  wrote:

On June 1, 2016 6:31:29 PM GMT+02:00, Esteban Lorenzano  
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

Re: [Pharo-dev] endless loop again

[stepharo]

Le 3/6/16 à 19:16, Esteban A. Maringolo a écrit :

Regarding the first part of your email, about UI lockups, it is almost
unavoidable, because in Pharo almost everything happens in the main
thread, as you pointed out.

Yes. This is all my point.


When only UI events should happen there,
and have background processes/async tasks for computation and I/O that
updates the UI by means of some sort of message channel between the
process and the UI.

This isn't a "feature" of Pharo only, other Smalltalks[1] have the
same "design" (or lack thereof) regarding what it is done in the main/UI thread.

:)


I can't imagine a plan for changing that in the current tools, I think
it would require a major overhaul.

I would like to see this point addressed. It would be good to have
less addition in Pharo before such point gets addressed.


OTOH newer tools like Spotter seems to use background threads to do
its stuff, so the shift might have already begun.

Regards,

Esteban A. Maringolo

[1] VisualAge came with an separate OS process that could halt the vm
at a very low level when it was stuck in a tight loop. ST/X has a
process/message queue per os window, which allows you to kill one
window without taking down the whole image/vm.

Yes in VW it is the same.


2016-06-03 2:56 GMT-03:00 stepharo :

the mooc is a mine for Pharo bugs...


In the video at 6:12, we have a new method sending the new message. I've
made similar mistakes and Pharo does lock up, but then the operating system
(Windows 10) kills the Pharo VM. (Or perhaps there's a bug in Pharo itself
which just crashes the whole VM. I can't tell the difference.)
Is that because it's a memory leak? Does the VM have a fixed amount of
memory available, or can it request more from the OS?
Is there a way to recover from this error without killing the whole VM?
Most GUI systems I've used have at least two threads so that pushing a
button doesn't lock up the whole UI if the task takes a while. Does Pharo
always lock up for long-running tasks, or does it have some kind of
threading ability too? If a background thread gets in an infinite loop, how
do you kill it without killing the whole VM?


here was my answer

The real answer is a bit more complex so I may write some approximations: -
what you did a really tight loops that fills up the memory really fast. -
depending on the OS the VM can or not (in its current state) allocate more.
In some versions it has to preallocate.
"Most GUI systems I've used have at least two threads so that pushing a
button doesn't lock up the whole UI if the task takes a while. Does Pharo
always lock up for long-running tasks, or does it have some kind of
threading ability too? If a background thread gets in an infinite loop, how
do you kill it without killing the whole VM?"
Pharo has a full model for concurrent programming. Check the class Process,
Semaphore. We have some stress tests that create thousands of threads
without problems. You have also package such TaskIt to schedule tasks
Now the actual problem that you see and that I would love to see fix in the
future is that the code you execute is run in the UI thread (argh) It is
still like that for historical reason. We should do one pass on that but
this is not that simple because it will raise a couple of bugs.


Now I think that it would be great if people from the pharo core would
browse in diagonal the problems that students

encounter because there are our real customers and they show many problems
of the system. Especially the ones we do not see anymore.

Re: [Pharo-dev] Debugger is not stable

[stepharo]

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.

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