Re: [Pharo-dev] why is gt playground not saving the code

[stepharo]

Le 31/8/16 à 22:10, Tudor Girba a écrit :

Hi,

The code should actually be saved on disk every time you type. Please take a 
look at the files from play-cache. Could you confirm?

One bug is that the history is cached and not refreshed, so when you re-open a 
crashed page the image does not know that there is another file. This has to be 
changed.


should protect it with a session check


As for having the currently opened playgrounds in the dropdown, we chose it 
like that because when you open the dropdown you typically want to switch to 
something else than what exists right now in front of view. Thus showing the 
same entry again would provide little value. I believe that if we would solve 
the history bug described above, this issue would resolve itself as well.

In any case, the dealing with the history of the playground is underdeveloped. 
So, let’s see if we can identify ways to improve the situation.

What do you think?

Cheers,
Doru



On Aug 31, 2016, at 12:00 PM, Peter Uhnák  wrote:

At this point I’ve lost cumulatively hours and hours of work due to Playground 
not saving the code; so every time I crash I lose.
  
In the picture below the code was demonstrably executed and yet it’s not in the history and if I would crash (which happens several times a day in “stable” pharo 5) I would lose it. Not to mention that way too often I see duplicate events in the history with identical code…
  

  
Peter



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

"Speaking louder won't make the point worthier."

Re: [Pharo-dev] About the non-use of Announcer in Bloc

[stepharo]

Le 31/8/16 à 11:23, Denis Kudriashov a écrit :


2016-08-31 10:10 GMT+02:00 Glenn Cavarlé >:


Hi all (I was out for some days),


Hi Glenn


What i see is that Bloc EventRegistry:
1) is not thread safe (no mutex + #select:thenDo:)
2) doesn't allow handler removal from the handler list currently
used in the
thenDo: loop
3) is used specifically for a one-to-many communication (1
BlElement -> X
handlers)

The (1) doesn't seem to be a problem in Bloc during UI event
processing
because a new event handler, even if it is added from another
thread, would
be taken into account for the next event.


Problem that concurrent modification of OrderedCollection could just 
fail. You will got debugger.


I note that it is really not
recommended (at all) to update an UI element elsewhere than in the
UI thread
and it is like that in all other UI frameworks i know.


Does it means that I should not subscribe on UI events from different 
(not UI) processes?

How to do this if it is needed?
Should I always put subscription code into #defer: message (analogue)?
In that case what to do if I need to be sure that I really subscribe 
on event and only after this continue my business logic process?



The (2) is a very specific use case and i don't know if it is a
real need in
Bloc because this implies that an element has 2 handlers for the
same event
and one of them has to remove the other before it is executed and
during the
same event processing (maybe more a conception issue than a common use
case...). In other cases, no problem for handler removal.


Very simple example: I want one shot handler for MouseMove to 
highlight element once to see that my mouse was moved around.
So my handler will highlight target element and unsubscribe it 
immediately.
Problem that if you do it on OrderedCollection during iteration you 
could skip one of the handlers. And probably some failures are also 
possible (debugger again).


Of course you could say users do not do all of this. But what the 
alternative? And if people will do this by "incident" it will be very 
difficult to discover reasons.



But maybe i miss some specific cases in (1) and in (2).

To me, Announcer is really usefull and efficient when it is used
as an event
bus that can be shared between multiple objects.
For instance, it seems to be useless to use an Announcer in
NewValueHolder
because it cannot be shared and it is only used internally to register
handlers and to propagate only the same event (ValueChanged) to
them. What
is the gain of using a full featured Announcer in this case?


But in practice we never share any announcer instance.
Really? You lost me on that sentence. SystemAnnouncer current is shared 
by all the tools no?


We always hide it inside owner object. ValueHolder is not specific 
example.
Also ValueHolder is kind of active model for UI application which 
could be shared between different views. And when it will be modified 
in one view another view will be updated automatically.



In Bloc the constraint is to propagate more than 2000
events/second without
to decrease fps, so we cannot afford to x4 the time to process
events even
if Announcer is safer and better tested.


I wondering what the source of this constraint? Does Morphic follows 
it? I guess not, but all Pharo works quite well with it.

Re: [Pharo-dev] About the non-use of Announcer in Bloc

[stepharo]

To me, Announcer is really usefull and efficient when it is used as an event
bus that can be shared between multiple objects.
For instance, it seems to be useless to use an Announcer in NewValueHolder
because it cannot be shared and it is only used internally to register
handlers and to propagate only the same event (ValueChanged) to them. What
is the gain of using a full featured Announcer in this case?
I particularly like these two points and I would really like to have a 
confirmation

because in that case this is really a place for improvements.



In Bloc the constraint is to propagate more than 2000 events/second without
to decrease fps, so we cannot afford to x4 the time to process events even
if Announcer is safer and better tested.

Regards,
Glenn.

Re: [Pharo-dev] About the non-use of Announcer in Bloc

[stepharo]

Hi thierry

I think that if we would have a tool to show us the activity I'm quite 
sure that we would find bugs


or mistaken behavior.

could you send the scripts you did?

Stef


Le 30/8/16 à 22:36, Thierry Goubier a écrit :

Numbers for the discussion:

No activity, empty desktop:
announcements608/minute
subscribe add/remove9/minute

Activity, AltBrowser:
announcements1109/minute
subscribe add/remove207/minute

Activity, Nautilus:
announcements2488/minute
subscribe add/remove716/minute

Empirically the same processus in both environments: open two system 
browser, in one, find the Announcer class, browse through a few of the 
methods, select basicSubscribe: and ask for senders.


Tracing done with Metalinks during one minute.

Not exactly what I would have expected, especially the ratio subscribe 
add/remove and announcements.


Thierry

Le 30/08/2016 à 17:36, Henrik Johansen a écrit :



On 30 Aug 2016, at 5:16 , Thierry Goubier
 wrote:


I have the same concern with an Announcer optimized for certain use
cases, in the fact that the announcer creator is the one choosing
the 'kind of' optimisation it would target, hoping that the
listeners will conform to that use case...



There simply is no silver bullet that will give unbeatable
performance in all scenarios; and focusing on improving one facet of
the default implementation will inevitably lead to either - the loss
of some important property (general thread-safety if removing the
mutex protection, ability to unsubscribe in handler if removing the
copy operation and extending the delivery mutex protection, etc.) -
greatly degenerated performance for another facet (like #remove for
OC's).

That said, the current implementation is very geared towards decent,
balanced subscribe/unsubscribe performance, at the expense of
delivery speed. I've said it before, and still think, that offering
at least one other implementation emphasizing delivery speed over
subscription/unsubscription performance, in the same way the original
implementation did (and/or changing the default Announcer to switch
between the two dynamically based on heuristics) *would* be a
valuable addition to the general library.

Cheers, Henry

Re: [Pharo-dev] why is gt playground not saving the code

[Esteban A. Maringolo]

2016-08-31 18:43 GMT-03:00 Tudor Girba :
> Hi,
>
>> On Aug 31, 2016, at 11:39 PM, Esteban A. Maringolo  
>> wrote:
>>
>> One use case that sometimes bites me is when I'm working in the "code"
>> of the Playground (first screen), and then I start going deep with
>> "Evaluate and Go", basically inspecting my objects, and then I close
>> the window thinking I'm dealing with an inspector hence losing the
>> code of the "workspace" in the Playground that started the inspection
>> "workflow", without receiving any warning about "losing" my changes.
>> I'd like an explicit "Save" in the Playground, but since I'm not
>> adding it, I can't complain much. :)
>
> Thanks for the input. What would the Save do in this case?

It should let me decide IF and WHEN to store the code contents.

Also, if you tests scripts in a workspace and evaluate them
"outside" of it (e.g. from the command line) I have to copy/paste the
contents back and forth from the Playground to a text editor to
save/modify something that in the past I did with the Workspace.

> Should the “save" save the code from the playground?

Yes.

> The code from the playground is actually not lost when you close the 
> Playground, and neither is the code you write in the Raw panes. Or is there a 
> different thing you have in mind?

Is not lost, but sometimes I want to reset it (reload) from a previous
saved state. Maybe the latest evaluation isn't what I want to recover.
Also the menu isn't the best option if you have several expressions
that start with the same characters and are indistinguishable from
each other.

I appreciate the "autosave" like feature (although I'd like to be able
to disable it for security paranoid concerns), but I also like to
decide when to save.

But the use case I pointed wasn't about storing the contents outside
of the playground but instead of getting a warning or something when
closing the Playground doing inspection. Sometimes I don't want to
close the playground, just want to reset everything to the original
code pane as if no "Evaluate and Go" was ever ran.

Regards!

Esteban A. Maringolo

Re: [Pharo-dev] why is gt playground not saving the code

[Tudor Girba]

Hi,

> On Aug 31, 2016, at 11:39 PM, Esteban A. Maringolo  
> wrote:
> 
> One use case that sometimes bites me is when I'm working in the "code"
> of the Playground (first screen), and then I start going deep with
> "Evaluate and Go", basically inspecting my objects, and then I close
> the window thinking I'm dealing with an inspector hence losing the
> code of the "workspace" in the Playground that started the inspection
> "workflow", without receiving any warning about "losing" my changes.
> I'd like an explicit "Save" in the Playground, but since I'm not
> adding it, I can't complain much. :)

Thanks for the input. What would the Save do in this case?

Should the “save" save the code from the playground? The code from the 
playground is actually not lost when you close the Playground, and neither is 
the code you write in the Raw panes. Or is there a different thing you have in 
mind?

Doru

> 
> Regards.
> 
> 
> Esteban A. Maringolo
> Esteban A. Maringolo
> 
> 
> 2016-08-31 17:10 GMT-03:00 Tudor Girba :
>> Hi,
>> 
>> The code should actually be saved on disk every time you type. Please take a 
>> look at the files from play-cache. Could you confirm?
>> 
>> One bug is that the history is cached and not refreshed, so when you re-open 
>> a crashed page the image does not know that there is another file. This has 
>> to be changed.
>> 
>> As for having the currently opened playgrounds in the dropdown, we chose it 
>> like that because when you open the dropdown you typically want to switch to 
>> something else than what exists right now in front of view. Thus showing the 
>> same entry again would provide little value. I believe that if we would 
>> solve the history bug described above, this issue would resolve itself as 
>> well.
>> 
>> In any case, the dealing with the history of the playground is 
>> underdeveloped. So, let’s see if we can identify ways to improve the 
>> situation.
>> 
>> What do you think?
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Aug 31, 2016, at 12:00 PM, Peter Uhnák  wrote:
>>> 
>>> At this point I’ve lost cumulatively hours and hours of work due to 
>>> Playground not saving the code; so every time I crash I lose.
>>> 
>>> In the picture below the code was demonstrably executed and yet it’s not in 
>>> the history and if I would crash (which happens several times a day in 
>>> “stable” pharo 5) I would lose it. Not to mention that way too often I see 
>>> duplicate events in the history with identical code…
>>> 
>>> 
>>> 
>>> Peter
>>> 
>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "Speaking louder won't make the point worthier."
>> 
>> 
> 

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

"Quality cannot be an afterthought."

Re: [Pharo-dev] why is gt playground not saving the code

[Esteban A. Maringolo]

One use case that sometimes bites me is when I'm working in the "code"
of the Playground (first screen), and then I start going deep with
"Evaluate and Go", basically inspecting my objects, and then I close
the window thinking I'm dealing with an inspector hence losing the
code of the "workspace" in the Playground that started the inspection
"workflow", without receiving any warning about "losing" my changes.

I'd like an explicit "Save" in the Playground, but since I'm not
adding it, I can't complain much. :)

Regards.


Esteban A. Maringolo
Esteban A. Maringolo


2016-08-31 17:10 GMT-03:00 Tudor Girba :
> Hi,
>
> The code should actually be saved on disk every time you type. Please take a 
> look at the files from play-cache. Could you confirm?
>
> One bug is that the history is cached and not refreshed, so when you re-open 
> a crashed page the image does not know that there is another file. This has 
> to be changed.
>
> As for having the currently opened playgrounds in the dropdown, we chose it 
> like that because when you open the dropdown you typically want to switch to 
> something else than what exists right now in front of view. Thus showing the 
> same entry again would provide little value. I believe that if we would solve 
> the history bug described above, this issue would resolve itself as well.
>
> In any case, the dealing with the history of the playground is 
> underdeveloped. So, let’s see if we can identify ways to improve the 
> situation.
>
> What do you think?
>
> Cheers,
> Doru
>
>
>> On Aug 31, 2016, at 12:00 PM, Peter Uhnák  wrote:
>>
>> At this point I’ve lost cumulatively hours and hours of work due to 
>> Playground not saving the code; so every time I crash I lose.
>>
>> In the picture below the code was demonstrably executed and yet it’s not in 
>> the history and if I would crash (which happens several times a day in 
>> “stable” pharo 5) I would lose it. Not to mention that way too often I see 
>> duplicate events in the history with identical code…
>>
>> 
>>
>> Peter
>> 
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Speaking louder won't make the point worthier."
>
>

Re: [Pharo-dev] Binary selector and special characters

[Thierry Goubier]

2016-08-31 20:55 GMT+02:00 Nicolai Hess :

>
>
> 2016-08-31 17:31 GMT+02:00 John Brant :
>
>> On 08/31/2016 08:46 AM, Nicolai Hess wrote:
>>
>> Anyone knows why RefactoringBrowsers smalltalk scanner (RBScanner)
>>> explicit allowes
>>>   "#($± $· $× $÷)" to be binary selector characters ?
>>>
>>
>> I do -- I added them about 20 years ago :)...
>>
>> Is there any smalltalk dialect that uses these characters ?
>>>
>>
>> VW allows them. When possible, we made the scanner/parser be a superset
>> of the VW & VA syntax.
>>
>>
>> John Brant
>>
>>
> Thank you John, for the info.
> Hm, now, what to do, fix our (pharo) parser to allowe these characters as
> binary selectors or change the scanner to not
> generate binary selector tokens for them...
>

I'd say change the parser to accept them.

Thierry

Re: [Pharo-dev] About Pharo 60

[Serge Stinckwich]

On Wed, Aug 31, 2016 at 9:16 PM, stepharo  wrote:
> In squeak by example
>
> we could tag in the document code snippet as text and a perl script
>
> turn the expression into Sunit method and run the tests
>
> We lost that.

Yes I remember this was very nice.

We should have a look to the org-babel env that I demonstrate shortly
during the ESUG "show us your project" session.
This based also on a markup language (org-mode) and you could use for
doing literate programming:
http://orgmode.org/worg/org-contrib/babel/

Some lessons should be extracted from that in order to enhance Pillar
in this direction also.

-- 
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/

Re: [Pharo-dev] why is gt playground not saving the code

[Peter Uhnak]

On Wed, Aug 31, 2016 at 10:10:21PM +0200, Tudor Girba wrote:
> Hi,
> 
> The code should actually be saved on disk every time you type. Please take a 
> look at the files from play-cache. Could you confirm?
> 
> One bug is that the history is cached and not refreshed, so when you re-open 
> a crashed page the image does not know that there is another file. This has 
> to be changed.
> 
> As for having the currently opened playgrounds in the dropdown, we chose it 
> like that because when you open the dropdown you typically want to switch to 
> something else than what exists right now in front of view. Thus showing the 
> same entry again would provide little value. I believe that if we would solve 
> the history bug described above, this issue would resolve itself as well.
> 
> In any case, the dealing with the history of the playground is 
> underdeveloped. So, let’s see if we can identify ways to improve the 
> situation.
> 
> What do you think?

Thank you both for the answers, I didn't know there was a disk storage that was 
independent of what was shown to me, so next time I crash I will check.
But there were other strange issues going around, or at least confusing. So 
I'll try to play with it a bit tomorrow.

Thanks,
Peter

Re: [Pharo-dev] why is gt playground not saving the code

[Tudor Girba]

Hi,

The code should actually be saved on disk every time you type. Please take a 
look at the files from play-cache. Could you confirm?

One bug is that the history is cached and not refreshed, so when you re-open a 
crashed page the image does not know that there is another file. This has to be 
changed.

As for having the currently opened playgrounds in the dropdown, we chose it 
like that because when you open the dropdown you typically want to switch to 
something else than what exists right now in front of view. Thus showing the 
same entry again would provide little value. I believe that if we would solve 
the history bug described above, this issue would resolve itself as well.

In any case, the dealing with the history of the playground is underdeveloped. 
So, let’s see if we can identify ways to improve the situation.

What do you think?

Cheers,
Doru


> On Aug 31, 2016, at 12:00 PM, Peter Uhnák  wrote:
> 
> At this point I’ve lost cumulatively hours and hours of work due to 
> Playground not saving the code; so every time I crash I lose.
>  
> In the picture below the code was demonstrably executed and yet it’s not in 
> the history and if I would crash (which happens several times a day in 
> “stable” pharo 5) I would lose it. Not to mention that way too often I see 
> duplicate events in the history with identical code…
>  
> 
>  
> Peter
> 

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

"Speaking louder won't make the point worthier."

Re: [Pharo-dev] About Pharo 60

[stepharo]

In squeak by example

we could tag in the document code snippet as text and a perl script

turn the expression into Sunit method and run the tests

We lost that.

Stef


Le 31/8/16 à 12:21, Peter Uhnak a écrit :

On Wed, Aug 31, 2016 at 12:00:30PM +0200, Yuriy Tymchuk wrote:

Ok, now I know what I want.

I want a better way to document. Because I’m trying to write a documentation 
about my stuff, but there are too many disconnected ways to do that. I’m trying 
to always have reasonable class comments. But sometimes you need a more general 
description, so you write help topics which are disconnected from class 
comments. Yes, we can add help topics generated from class comments but that’s 
too weak. Additionally I version my projects on github, so I want t doc there 
in readme, or on a wiki. What’s more I think that it’s a good idea to export 
doc to the web. Because when someone mentioned package manifest I started to 
google for it and could not find anything.

My suggestions:
- write comments in pillar and slowly add pillar support to enrich comment 
(documentation) styles
- add a possibility to reference classes/methods and help topics from pillar 
comments
- have exporters to generate html documentation about a project based on 
comments and help topics
- then I will be able to add a hook to Icebeg telling it: ok, on commit also 
generate a doc and export it as MarkDown (because we can) and commit it as a 
README or as a wiki entry or whatever.

This way we will have interconnected documentation in the image, and if it 
should be placed somewhere else we export it.

+14.

Knowing that I cannot verify that the documentation is sync with code is very 
discouraging to even start writing the docs. When I was writing a chapter for 
agile visualization, I had the examples as independent scripts which I could 
execute (I believe Pillar has added executable examples since then).

But there are more things than examples, e.g. a Travis could run "docs 
verification" that would look at all the code (so even method and class name 
references) and made sure they exist and are not, say, deprecated. As Pillar provides you 
with a real syntax tree this might not be so hard.

At least personally the above could be a real value for me with Pillar, because 
up until now it was just another document format (and there's a lot of better 
ones) with poor infrastructure. But deep integration with Pharo could make it 
really valuable, and we are getting there.


- then I will be able to add a hook to Icebeg telling it: ok, on commit also 
generate a doc and export it as MarkDown (because we can) and commit it as a 
README or as a wiki entry or whatever.

so close :) 
https://github.com/peteruhnak/IconFactory/blob/master/repository/BaselineOfIconFactory.package/BaselineOfIconFactory.class/class/updateReadme.st

Peter

Re: [Pharo-dev] Binary selector and special characters

[Nicolai Hess]

2016-08-31 17:31 GMT+02:00 John Brant :

> On 08/31/2016 08:46 AM, Nicolai Hess wrote:
>
> Anyone knows why RefactoringBrowsers smalltalk scanner (RBScanner)
>> explicit allowes
>>   "#($± $· $× $÷)" to be binary selector characters ?
>>
>
> I do -- I added them about 20 years ago :)...
>
> Is there any smalltalk dialect that uses these characters ?
>>
>
> VW allows them. When possible, we made the scanner/parser be a superset of
> the VW & VA syntax.
>
>
> John Brant
>
>
Thank you John, for the info.
Hm, now, what to do, fix our (pharo) parser to allowe these characters as
binary selectors or change the scanner to not
generate binary selector tokens for them...

Re: [Pharo-dev] About the non-use of Announcer in Bloc

[Thierry Goubier]

2016-08-31 18:01 GMT+02:00 Henrik Johansen :

>
> On 31 Aug 2016, at 10:10 , Glenn Cavarlé  wrote:
>
> In Bloc the constraint is to propagate more than 2000 events/second without
> to decrease fps
>
>
> That's only a small part of the picture though, how many listeners are
> there per each event?
> And how large do you think the overhead specific to delivery guards is
> compared to the constraint propagation handlers?
>
> On my machine (an old 2011 MBP), the following gives throughput on the
> order of 300k-600k deliveries per second (very variable, due to the amount
> of garbage generated from copying subs, I presume)
>

So close to 3 times the performance of entry-level celeron for laptops
today (if I take the lowest of the 15" MBP of early 2011).


>
> #(1 10 100 1000) collect: [ :listeners |
>
> a := Announcer new.
> b := Object new.
> "Single message send in handler"
> listeners timesRepeat: [a when: Announcement do: [ :a | a yourself ] for:
> b.].
> "announcement creation overhead not included"
> ann := Announcement new.
> [a announce: ann] bench].
>
> Cheers,
> Henry
>
> And with a registry tuned for delivery, yet maintaining the guards
> (attached)/exception/error handling properties, 900k -> 2.5M
>
> #(1 10 100 1000) collect: [ :listeners |
>
> a := Announcer new.
> b := Object new.
> a instVarNamed: 'registry' put: DeliveringSubscriptionRegistry new.
> "Single message send in handler"
> listeners timesRepeat: [a when: Announcement do: [ :a | a yourself ] for:
> b.].
> "announcement creation overhead not included"
> ann := Announcement new.
> [a announce: ann] bench.].
>

Thanks for the numbers. We need those to optimise what really matters :)

Thierry

Re: [Pharo-dev] About the non-use of Announcer in Bloc

[Henrik Johansen]

On 31 Aug 2016, at 10:10 , Glenn Cavarlé  wrote:In Bloc the constraint is to propagate more than 2000 events/second withoutto decrease fpsThat's only a small part of the picture though, how many listeners are there per each event?And how large do you think the overhead specific to delivery guards is compared to the constraint propagation handlers?On my machine (an old 2011 MBP), the following gives throughput on the order of 300k-600k deliveries per second (very variable, due to the amount of garbage generated from copying subs, I presume) #(1 10 100 1000) collect: [ :listeners | a := Announcer new. b := Object new."Single message send in handler"listeners timesRepeat: [a when: Announcement do: [ :a | a yourself ] for: b.]."announcement creation overhead not included"ann := Announcement new.[a announce: ann] bench].Cheers, HenryAnd with a registry tuned for delivery, yet maintaining the guards (attached)/exception/error handling properties, 900k -> 2.5M#(1 10 100 1000) collect: [ :listeners | a := Announcer new. b := Object new.a instVarNamed: 'registry' put: DeliveringSubscriptionRegistry new. "Single message send in handler"listeners timesRepeat: [a when: Announcement do: [ :a | a yourself ] for: b.]."announcement creation overhead not included"ann := Announcement new.[a announce: ann] bench.].

DeliveringSubscriptionRegistry.st
Description: Binary data


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] Binary selector and special characters

[John Brant]

On 08/31/2016 08:46 AM, Nicolai Hess wrote:


Anyone knows why RefactoringBrowsers smalltalk scanner (RBScanner)
explicit allowes
  "#($± $· $× $÷)" to be binary selector characters ?


I do -- I added them about 20 years ago :)...


Is there any smalltalk dialect that uses these characters ?


VW allows them. When possible, we made the scanner/parser be a superset 
of the VW & VA syntax.



John Brant

Re: [Pharo-dev] Binary selector and special characters

[Nicolai Hess]

2016-08-31 10:14 GMT+02:00 Eliot Miranda :

> Oops.  No need to add a step method; the increment method already exists:
>
>
>
On Wed, Aug 31, 2016 at 9:12 AM, Eliot Miranda 
> wrote:
>
>>
>>
>> On Tue, Aug 30, 2016 at 8:14 AM, Nicolai Hess 
>> wrote:
>>
>>>
>>>
>>> 2016-08-29 21:38 GMT+02:00 Thierry Goubier :
>>>
 Le 29/08/2016 à 21:28, stepharo a écrit :

>
>
> Le 29/8/16 à 17:45, Thierry Goubier a écrit :
>
>> Hi Stef,
>>
>> 2016-08-29 11:42 GMT+02:00 stepharo > >:
>>
>> Thierry
>>
>> If you have a better editor control even better :)
>>
>>>
>>> Syntax wise, one could consider "" to be inside a comment (i.e.
>>> do not split into two comments if encountered inside a comment,
>>> as it is done now).
>>>
>> This one could be nice too :)
>>
>>
>>  https://pharo.fogbugz.com/f/cases/19011/Integrate-two-doubl
>> e-quotes-inside-comments
>>
>> I'll have the slice ready soon. Any comments on what that would mean
>> regarding the Smalltalk commonly accepted syntax if that feature is
>> integrated?
>>
> It will break compatibility for people using it now we should raise the
> topic and lets a chance to people to discuss about it. We could check
> before publishing if code contain nested comments.
>

 Hum. The slice should parse anything legal Smalltalk; just that it may
 show less comments intervals (because in fact it will coalesce adjacent
 comments).

>>>
>>> Yes, I think the change for RBScanner is fine, it does not changes what
>>> kind of comments are accepted, only how they are assigned to
>>> the AST nodes (one vs. multiple comments).
>>>
>>> (BTW. do we have a function that would do the coalescing of intervals:
>>>
>>> (1 to:99) (100 to: 199) -> (1 to:199)
>>>
>>> ? )
>>>
>>
>> Find attached something that works in Squeak 5
>>
>
Nice,
But actually I wasn't clear about the requirements :-)

The purpose was to merge source code intervals after parsing code comments.
The comments may be adjacent and could be merged into one comment. For this
I would like to merge an collection of intervals in  a smaller number of
intervals with adjacent intervals merged into one:

{ (30 to: 35) . (36 to:40) . (50 to:100) }
-> { (30 to:40) . (50 to:100) }

But Thierry already changed the scanner to produce this smaller set of
intervals/comments :-)


>> For example, standard parse will say that:

 '"this ""test"' is a token with two comments, intervals 1 to: 7 and 8
 to: 13.

 The slice makes that a single comment:

 '"this ""test"' is a token with one comment, interval 1 to: 13.

 Now, this has probably no impact on parsing smalltalk code. But it
 changes a bit the language definition, so that's why I'd like comments on
 it.

 I think that I would use them only when developing.
>

 Up to you :)

 The most interesting is to have the correct comment/uncomment behavior
 in an editor... that one works independently and is quite cool.

 Thierry

 Stef
>
>
>> Thierry
>>
>
>> _,,,^..^,,,_
>> best, Eliot
>>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>

Re: [Pharo-dev] Binary selector and special characters

[Nicolai Hess]

2016-08-29 11:23 GMT+02:00 Nicolai Hess :

>
>
> 2016-08-28 13:41 GMT+02:00 monty :
>
>> See RBParserTest>>#testBinarySelectors
>>
>> It's based on the draft ANSI Smalltalk-80 standard. You integrated it. It
>> tests the RBParser's parsing of binary method definitions and message sends
>> of all binary selectors from 1 char upto 3 chars. (The Blue Book is more
>> restrictive than ANSI, limiting them to 2 chars max IIRC.)
>>
>> I wrote the test because of issues I had with the OldCompiler's handling
>> of selectors containing "|" and issues on other platforms like GemStone, so
>> the behavior I need and think is correct won't get broken without warning.
>>
>>
> Hi Monty,
> yes, but I am just wondering why the scanner interprets some characters as
> binary selector token, whereas they are not allowed as binary selectors.
> In the old scanner, the initialization of the type table just sets "
> binary token" as the default for all characters and changes some of them
> explicit to for example
>
>  ($0 asciiValue to: $9 asciiValue) -> digit tokens
>  #(9 10 12 13 32 )  -> delimiter  token
> ...
>
> But RBScanner on the other hand explicitly sets some non-ascii characters
> to be used as "binary tokens"
>
> classificationTable at: 177 put: #binary."plus-or-minus"
> classificationTable at: 183 put: #binary."centered dot"
> classificationTable at: 215 put: #binary."times"
> classificationTable at: 247 put: #binary."divide"
>
> It looks like someone ( or somewhere )  it should be allowed to use these
> characters as a binary selector
>  "#($± $· $× $÷)"
> Although later at the parsing step, using this tokens for binary message
> selectors isn't allowed.
>
> I think I will exclude these characters as binary selector tokens.
>
>

Now back ontopic :)

Anyone knows why RefactoringBrowsers smalltalk scanner (RBScanner) explicit
allowes
 "#($± $· $× $÷)" to be binary selector characters ?
Is there any smalltalk dialect that uses these characters ?

I think I 'll remove the support for this in Pharo (it actually isn't
really supported, althought the scanner scannes these characters
as binary selector tokens, the parser finally does not allow these
characters as binary selector symbols.

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 36483e: 60196

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 36483e309d746cb796ae363a3a5a1555c5c2883a
  
https://github.com/pharo-project/pharo-core/commit/36483e309d746cb796ae363a3a5a1555c5c2883a
  Author: Jenkins Build Server 
  Date:   2016-08-31 (Wed, 31 Aug 2016)

  Changed paths:
M AST-Core.package/RBScanner.class/instance/private-scanning/stripComment.st
A 
AST-Tests-Core.package/RBScannerTest.class/instance/next/testNextWithTwoDoubleQuotesInComment.st
A 
AST-Tests-Core.package/RBScannerTest.class/instance/next/testNextWithTwoDoubleQuotesInCommentGetError.st
R BlueInk-Extras.package/BIInspector.class/README.md
R BlueInk-Extras.package/BIInspector.class/class/build ui 
buttons/buildOpenBIInspectorButton.st
R BlueInk-Extras.package/BIInspector.class/class/button 
behavior/openBIInspectorButtonAction.st
R BlueInk-Extras.package/BIInspector.class/class/button 
behavior/openBIInspectorButtonLabel.st
R BlueInk-Extras.package/BIInspector.class/class/button 
behavior/openBIInspectorButtonState.st
R 
BlueInk-Extras.package/BIInspector.class/class/settings/dialogOpenBIInspector.st
R BlueInk-Extras.package/BIInspector.class/class/settings/settingsOn_.st
R BlueInk-Extras.package/BIInspector.class/class/specs/defaultSpec.st
R BlueInk-Extras.package/BIInspector.class/definition.st
R 
BlueInk-Extras.package/BIInspector.class/instance/accessing/classSearchField.st
R 
BlueInk-Extras.package/BIInspector.class/instance/accessing/compiledMethodFromSearchFields.st
R 
BlueInk-Extras.package/BIInspector.class/instance/accessing/formattedCheckBox.st
R 
BlueInk-Extras.package/BIInspector.class/instance/accessing/methodSearchField.st
R 
BlueInk-Extras.package/BIInspector.class/instance/accessing/settingsTree.st
R 
BlueInk-Extras.package/BIInspector.class/instance/accessing/sourceCodePane.st
R BlueInk-Extras.package/BIInspector.class/instance/api/formatSourceCode.st
R BlueInk-Extras.package/BIInspector.class/instance/api/initialExtent.st
R BlueInk-Extras.package/BIInspector.class/instance/api/title.st
R BlueInk-Extras.package/BIInspector.class/instance/event 
handling/whenASettingChanged.st
R BlueInk-Extras.package/BIInspector.class/instance/event 
handling/whenSelectorAccepted.st
R 
BlueInk-Extras.package/BIInspector.class/instance/initialization/initializeWidgets.st
R BlueInk-Extras.package/BIInspector.class/instance/item 
creation/buildClassSearchField.st
R BlueInk-Extras.package/BIInspector.class/instance/item 
creation/buildFormattedCheckBox.st
R BlueInk-Extras.package/BIInspector.class/instance/item 
creation/buildMethodSearchField.st
R BlueInk-Extras.package/BIInspector.class/instance/item 
creation/buildSettingsTreeModel.st
R BlueInk-Extras.package/BIInspector.class/instance/item 
creation/buildSourceCodePane.st
R BlueInk-Extras.package/BIInspector.class/instance/item 
creation/displayNodeFor_.st
R 
BlueInk-Extras.package/BIInspector.class/instance/testing/selectorAndClassAreCorrect.st
A BlueInk-Extras.package/BISettingPreviewer.class/README.md
A BlueInk-Extras.package/BISettingPreviewer.class/class/build ui 
buttons/buildOpenBIInspectorButton.st
A BlueInk-Extras.package/BISettingPreviewer.class/class/button 
behavior/openBIInspectorButtonAction.st
A BlueInk-Extras.package/BISettingPreviewer.class/class/button 
behavior/openBIInspectorButtonLabel.st
A BlueInk-Extras.package/BISettingPreviewer.class/class/button 
behavior/openBIInspectorButtonState.st
A 
BlueInk-Extras.package/BISettingPreviewer.class/class/settings/dialogOpenBIPreviewer.st
A 
BlueInk-Extras.package/BISettingPreviewer.class/class/settings/settingsOn_.st
A BlueInk-Extras.package/BISettingPreviewer.class/class/specs/defaultSpec.st
A BlueInk-Extras.package/BISettingPreviewer.class/definition.st
A 
BlueInk-Extras.package/BISettingPreviewer.class/instance/accessing/classSearchField.st
A 
BlueInk-Extras.package/BISettingPreviewer.class/instance/accessing/compiledMethodFromSearchFields.st
A 
BlueInk-Extras.package/BISettingPreviewer.class/instance/accessing/formattedCheckBox.st
A 
BlueInk-Extras.package/BISettingPreviewer.class/instance/accessing/methodSearchField.st
A 
BlueInk-Extras.package/BISettingPreviewer.class/instance/accessing/settingsTree.st
A 
BlueInk-Extras.package/BISettingPreviewer.class/instance/accessing/sourceCodePane.st
A 
BlueInk-Extras.package/BISettingPreviewer.class/instance/api/formatSourceCode.st
A 
BlueInk-Extras.package/BISettingPreviewer.class/instance/api/initialExtent.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/api/title.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/event 
handling/whenASettingChanged.st
A BlueInk-Extras.package/BISettingPreviewer.class/instance/event 
handling/whenSelectorAccepted.st
A 
BlueInk-Extras.package/BISettingPreviewer.class/instance/i

[Pharo-dev] SUnit improvements need review and feedback

[Denis Kudriashov]

Hi.

I am working on SUnit improvements. I open issue 19015
.
Slice is inbox which waits your review and feedback.
I was trying to address three problems:

*1) Tests should never hang. They should be always executed within time
limit.*

I give them 10 minutes for now to not change existing behaviour of tests.
At next step it should be  really reduced to ~100 milliseconds (?).
Any TestCase could redefine time limit by method #defaultTimeLimit.
Or it could be specified directly in test code by
self timeLimit: 10 seconds
(could be changed at any time of test execution).

To implement this logic special watch dog process is running for given test
suite to control execution time of tests. It is single process for full
test suite.

*2) When test completes all forked processes should be terminated.*

If your tested code produced zombie processes SUnit will take care about
destroying all such garbage.
(it not means that you don't need to clean table in #tearDown but any code
could be broken and running tests should not produce dirty system).

*3) Any failures inside forked processes should not spawn debugger while
running tests.*
Only when we debug tests we need debugger on forked failed processes.
During normal run SUnit should prevent such "background debuggers" and mark
such tests as failed.

To implement this behaviour SUnit will handle errors from forked processes
by suspending them and collecting them in special collection.
I introduce TestFailedByForkedProcess error to signal these kind of
problems at the end of tests. This error is resumable and resume will opens
debuggers of suspended failures (in fact it will resume suspended
processes).
So to debug background failures you will need extra Proceed action on
debugger when TestFailedByForkedProcess is signalled.
But in normal run such tests will be just failed by
TestFailedByForkedProcess error.

*Now details on how it is done:*

I introduce special process specific variable CurrentExecutionEnvironment.
It is not installed by default and as default value it returns
DefaultExecutionEnvironment instance.
This variable is inheritable. If your install concrete environment into
process it will be installed to any child process.

So value of variable is instance of ExecutionEnvironment subclasses and you
can install it by:

anYourExecutionEnvironment beActiveDuring: aBlock


When block completes previous environment is restored.
For default environment there is class side method:

DefaultExecutionEnvironment beActiveDuring: aBlock


And to reset current environment to default:

DefaultExecutionEnvironment beActive.


SUnit introduces TestExecutionEnvironment which implements all described
behaviour for time limits and forked processes.
To activate environment there is new method #runCaseManaged. And submitted
slice uses it instead of simple runCase.

TestCase>>runCaseManaged
CurrentExecutionEnvironment runTestCase: self


DefaultExecutionEnvironment will install new TestExecutionEnvironment and
delegate processing to it. And if TestExecutionEnvironment is already
active it will just process new test case.

Now monkey has problem in checking slice (annoying timeout for loading).
So I can't see real system impact. But it should not stop you from review
:))
I think it is very important features for all our tests. And environment
idea will lead to very interesting future.

Best regards,
Denis

Re: [Pharo-dev] About the non-use of Announcer in Bloc

[Glenn Cavarlé]

Hi Denis,

> Problem that concurrent modification of OrderedCollection could just fail.
> You will got debugger.

Yes, effectively, if there are multiple threads that try to add an handler
on the same element at the same time, this could just fail.
To me, it is not a problem, it is just a rule: the scene graph is not
thread-safe.
When a developper have to do this kind of specific stuff, he has to know
that it is really not recommended and that he has to manage concurrency by
hand.
But yes, he could use #runLater:.
Maybe, Bloc will have to provide kind of Task (using TaskIt?) with a
specific api to ease ui synchronization using concurrency (later).


> In that case what to do if I need to be sure that I really subscribe on
> event and only after this continue my business logic process?

Weird use case, you mean that sometime your business behavior declared after
a subscription needs that the subscription have to be called before
continue?
Please can you be more explicit? For what i understand, it look like a
workaround or a conception issue. 


> Very simple example: I want one shot handler for MouseMove to highlight
> element once to see that my mouse was moved around.
> So my handler will highlight target element and unsubscribe it
> immediately.
> Problem that if you do it on OrderedCollection during iteration you could
> skip one of the handlers. And probably some failures are also possible
> (debugger again).

Yes, thanks for pointing this issue, i didn't remember that #select:thenDo:
uses the index at each iteration.
I will update that using (handlers select:[...]) do:[...] instead. Since
#select: create a new collection, there should not be any problem.


> But in practice we never share any announcer instance. We always hide it
> inside owner object. ValueHolder is not specific example.
> Also ValueHolder is kind of active model for UI application which could be
> shared between different views. And when it will be modified in one view
> another view will be updated automatically.

I know what is a ValueHolder and how data binding is usefull in GUI.
I didn't say that NewValueHolder and Announcer are not good and i don't
think that, i just asked myself about why the use of Announcer in
NewValueHolder make it 5x slower only to ensure that it is thread-safe while
in most cases, all stuff is done in one thread.
It is why i didn't use NewValueHolder in Bloc. (I commited tests between
NewValueHolder and BlObservableProperty in Bloc-Tests).  

If performances was not a critical issue in Bloc, obviously i would have
used NewValueHolder and Announcer because there are well done and well
tested.


> I wondering what the source of this constraint? Does Morphic follows it? I
> guess not, but all Pharo works quite well with it. 

Just move you mouse quickly on screen and think about how many
MouseMoveEvent are generated by the system.
Yes, Morphic follows it. Morphic doesn't use Announcer for UI events and
concurrent modifications of a morph seems to be not thread-safe.



-
Glenn Cavarlé
--
View this message in context: 
http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008p4913412.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] why is gt playground not saving the code

[Andrei Chis]

On Wed, Aug 31, 2016 at 12:32 PM, Nicolai Hess 
wrote:

>
>
> 2016-08-31 12:00 GMT+02:00 Peter Uhnák :
>
>> At this point I’ve lost cumulatively hours and hours of work due to
>> Playground not saving the code; so every time I crash I lose.
>>
>>
>>
>> In the picture below the code was demonstrably executed and yet it’s not
>> in the history and if I would crash (which happens several times a day in
>> “stable” pharo 5) I would lose it. Not to mention that way too often I see
>> duplicate events in the history with identical code…
>>
>>
>>
>>
>>
>
> This was discussed  a couple of time and we even had some bug-entries.
> But it is working that way "by-design".
> I don't understand why, but the current content is not shown in the
> history, only if you close the current playground window *withouth*
> deleteing the content.
>

I do not remember the previous discussion in details but I think we should
consider this a bug.
I'll open a bug report and try to dig the previous discussion about this
topic.

Cheers,
Andrei


> If the content is not shown in the history, it may be still in the
> play-cache folder.
>
>
>
>> Peter
>>
>
>

Re: [Pharo-dev] why is gt playground not saving the code

[Nicolai Hess]

2016-08-31 12:00 GMT+02:00 Peter Uhnák :

> At this point I’ve lost cumulatively hours and hours of work due to
> Playground not saving the code; so every time I crash I lose.
>
>
>
> In the picture below the code was demonstrably executed and yet it’s not
> in the history and if I would crash (which happens several times a day in
> “stable” pharo 5) I would lose it. Not to mention that way too often I see
> duplicate events in the history with identical code…
>
>
>
>
>

This was discussed  a couple of time and we even had some bug-entries.
But it is working that way "by-design".
I don't understand why, but the current content is not shown in the
history, only if you close the current playground window *withouth*
deleteing the content.
If the content is not shown in the history, it may be still in the
play-cache folder.



> Peter
>

[Pharo-dev] [pharo-project/pharo-core] 9d68e3: 60195

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 9d68e35455cae474b2ec8b645213c3dd32b9bed7
  
https://github.com/pharo-project/pharo-core/commit/9d68e35455cae474b2ec8b645213c3dd32b9bed7
  Author: Jenkins Build Server 
  Date:   2016-08-31 (Wed, 31 Aug 2016)

  Changed paths:
M Collections-Abstract.package/Collection.class/instance/testing/ifEmpty_.st
M 
Collections-Abstract.package/Collection.class/instance/testing/ifNotEmpty_.st
M Kernel-Tests.package/FractionTest.class/instance/tests - 
conversions/testIsPowerOfTwo.st
A 
Kernel-Tests.package/SemaphoreTest.class/instance/tests/testWaitTimeDuration.st
A 
Kernel-Tests.package/SemaphoreTest.class/instance/tests/testWaitTimeDurationWithCompletionAndTimeoutBlocks.st
M Kernel.package/Fraction.class/instance/testing/isPowerOfTwo.st
M Kernel.package/Point.class/instance/extent functions/scaleTo_.st
A Kernel.package/Semaphore.class/instance/communication/wait_.st
A 
Kernel.package/Semaphore.class/instance/communication/wait_onCompletion_onTimeout_.st
A Polymorph-Widgets-Rules.package/IconHardcodedMessageRule.class/README.md
A 
Polymorph-Widgets-Rules.package/IconHardcodedMessageRule.class/definition.st
A 
Polymorph-Widgets-Rules.package/IconHardcodedMessageRule.class/instance/accessing/group.st
A 
Polymorph-Widgets-Rules.package/IconHardcodedMessageRule.class/instance/accessing/name.st
A 
Polymorph-Widgets-Rules.package/IconHardcodedMessageRule.class/instance/accessing/severity.st
A 
Polymorph-Widgets-Rules.package/IconHardcodedMessageRule.class/instance/initialization/initialize.st
A Polymorph-Widgets-Rules.package/IconShortcutRule.class/README.md
A Polymorph-Widgets-Rules.package/IconShortcutRule.class/definition.st
A 
Polymorph-Widgets-Rules.package/IconShortcutRule.class/instance/accessing/group.st
A 
Polymorph-Widgets-Rules.package/IconShortcutRule.class/instance/accessing/name.st
A 
Polymorph-Widgets-Rules.package/IconShortcutRule.class/instance/accessing/severity.st
A 
Polymorph-Widgets-Rules.package/IconShortcutRule.class/instance/initialization/initialize.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60194.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
scripts/script60195.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60194.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - 
updates/update60195.st
M 
ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
A Text-Core.package/Text.class/instance/accessing/includesSubstring_.st
A 
Text-Core.package/Text.class/instance/accessing/includesSubstring_caseSensitive_.st
A 
Text-Tests.package/TextAndTextStreamTest.class/instance/tests/testIncludesSubstring.st
A 
Text-Tests.package/TextAndTextStreamTest.class/instance/tests/testIncludesSubstringCaseSensitive.st

  Log Message:
  ---
  60195
18033 Fraction isPowerOfTwo does too much work
https://pharo.fogbugz.com/f/cases/18033

19012 Added rules for icons
https://pharo.fogbugz.com/f/cases/19012

19013 Semaphore wait protocol based on duration
https://pharo.fogbugz.com/f/cases/19013

19005 Collection>>#ifEmpty: has useless return and wrong comment
https://pharo.fogbugz.com/f/cases/19005

18990 Text missing #includesSubstring: and includesSubstring:caseSensitive:
https://pharo.fogbugz.com/f/cases/18990

http://files.pharo.org/image/60/60195.zip

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

Re: [Pharo-dev] About Pharo 60

[Peter Uhnak]

On Wed, Aug 31, 2016 at 12:00:30PM +0200, Yuriy Tymchuk wrote:
> Ok, now I know what I want.
> 
> I want a better way to document. Because I’m trying to write a documentation 
> about my stuff, but there are too many disconnected ways to do that. I’m 
> trying to always have reasonable class comments. But sometimes you need a 
> more general description, so you write help topics which are disconnected 
> from class comments. Yes, we can add help topics generated from class 
> comments but that’s too weak. Additionally I version my projects on github, 
> so I want t doc there in readme, or on a wiki. What’s more I think that it’s 
> a good idea to export doc to the web. Because when someone mentioned package 
> manifest I started to google for it and could not find anything.
> 
> My suggestions:
> - write comments in pillar and slowly add pillar support to enrich comment 
> (documentation) styles
> - add a possibility to reference classes/methods and help topics from pillar 
> comments
> - have exporters to generate html documentation about a project based on 
> comments and help topics
> - then I will be able to add a hook to Icebeg telling it: ok, on commit also 
> generate a doc and export it as MarkDown (because we can) and commit it as a 
> README or as a wiki entry or whatever.
> 
> This way we will have interconnected documentation in the image, and if it 
> should be placed somewhere else we export it.

+14.

Knowing that I cannot verify that the documentation is sync with code is very 
discouraging to even start writing the docs. When I was writing a chapter for 
agile visualization, I had the examples as independent scripts which I could 
execute (I believe Pillar has added executable examples since then).

But there are more things than examples, e.g. a Travis could run "docs 
verification" that would look at all the code (so even method and class name 
references) and made sure they exist and are not, say, deprecated. As Pillar 
provides you with a real syntax tree this might not be so hard.

At least personally the above could be a real value for me with Pillar, because 
up until now it was just another document format (and there's a lot of better 
ones) with poor infrastructure. But deep integration with Pharo could make it 
really valuable, and we are getting there.

> - then I will be able to add a hook to Icebeg telling it: ok, on commit also 
> generate a doc and export it as MarkDown (because we can) and commit it as a 
> README or as a wiki entry or whatever.

so close :) 
https://github.com/peteruhnak/IconFactory/blob/master/repository/BaselineOfIconFactory.package/BaselineOfIconFactory.class/class/updateReadme.st

Peter

[Pharo-dev] why is gt playground not saving the code

[Peter Uhnák]

At this point I’ve lost cumulatively hours and hours of work due to Playground 
not saving the code; so every time I crash I lose.

In the picture below the code was demonstrably executed and yet it’s not in the 
history and if I would crash (which happens several times a day in “stable” 
pharo 5) I would lose it. Not to mention that way too often I see duplicate 
events in the history with identical code…



Peter

Re: [Pharo-dev] About Pharo 60

[Yuriy Tymchuk]

Ok, now I know what I want.

I want a better way to document. Because I’m trying to write a documentation 
about my stuff, but there are too many disconnected ways to do that. I’m trying 
to always have reasonable class comments. But sometimes you need a more general 
description, so you write help topics which are disconnected from class 
comments. Yes, we can add help topics generated from class comments but that’s 
too weak. Additionally I version my projects on github, so I want t doc there 
in readme, or on a wiki. What’s more I think that it’s a good idea to export 
doc to the web. Because when someone mentioned package manifest I started to 
google for it and could not find anything.

My suggestions:
- write comments in pillar and slowly add pillar support to enrich comment 
(documentation) styles
- add a possibility to reference classes/methods and help topics from pillar 
comments
- have exporters to generate html documentation about a project based on 
comments and help topics
- then I will be able to add a hook to Icebeg telling it: ok, on commit also 
generate a doc and export it as MarkDown (because we can) and commit it as a 
README or as a wiki entry or whatever.

This way we will have interconnected documentation in the image, and if it 
should be placed somewhere else we export it.

Cheers.
Uko

> On 24 Aug 2016, at 06:59, stepharo  wrote:
> 
> Hi
> 
> We have some ideas (because people are working on items) for the Pharo 6 
> roadmap
> 
> and we will consolidate them soon and propose them to you.
> 
> but I would like to know two kinds of points
> 
>- what are the points you are working on and that would deserve more focus 
> and help from the community?
> 
>(these points are important because like that you could go faster and 
> this is a good feeling to get done for example)
> 
>- what would be points where (if magically we would get more resources - 
> to not dream if this is not you
> 
>there is a high chance that we will not make it) it would be nice to 
> get some changes
> 
> 
> Please pay attention that if you type too fast and come up with a christmas 
> list well it will stay a christmas list and will just make the thread larger 
> for nothing.
> 
> Stef
> 
> 

Re: [Pharo-dev] [pharo-project/pharo-core] 518075: 60194

[Marcus Denker]

> On 31 Aug 2016, at 11:29, GitHub  wrote:
> 
> 
>  Log Message:
>  ---
>  60194
> Moose
> 
> http://files.pharo.org/image/60/60194.zip
> 
> 

This update contains:

- case 18965 (removed GTExample)

- case 18596
Remove references from Glamour to Smalltalk evaluate:

- case 18948
remove a direct reference to Compiler from GT tests

- case 18923
inspector: improve "list methods using this variable"

- case 18905
cleanup #withThorougMethodsReferTo:do:


Marcus

[Pharo-dev] [pharo-project/pharo-core]

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 518075: 60194

[GitHub]

  Branch: refs/heads/6.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 518075095836b300fd9be99765a1f918ed5884f2
  
https://github.com/pharo-project/pharo-core/commit/518075095836b300fd9be99765a1f918ed5884f2
  Author: Jenkins Build Server 
  Date:   2016-08-31 (Wed, 31 Aug 2016)

  Changed paths:
M 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic
 versions/development_.st
M 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version30_.st
A 
ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version31_.st
M 
ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/symbolic
 versions/development_.st
M 
ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version10_.st
A 
ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version11_.st
A 
ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/baselines/baseline30_.st
M 
ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic
 versions/development_.st
M 
ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version319_.st
M 
ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic
 versions/development_.st
M 
ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version315_.st
M 
ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic
 versions/development_.st
M 
ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version216_.st
M 
ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic
 versions/development_.st
M 
ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version327_.st
A 
ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/baselines/baseline40_.st
M 
ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic
 versions/development_.st
M 
ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic
 versions/stable_.st
A 
ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version421_.st
A GT-EventRecorder.package/GTBasicRecorderEvent.class/README.md
A GT-EventRecorder.package/GTBasicRecorderEvent.class/definition.st
A GT-EventRecorder.package/GTBasicRecorderEvent.class/instance/accessing - 
announcement info/announcementTimestamp.st
A GT-EventRecorder.package/GTBasicRecorderEvent.class/instance/accessing - 
announcement info/computerUUID.st
A GT-EventRecorder.package/GTBasicRecorderEvent.class/instance/accessing - 
announcement info/eventRecorderVersion.st
A GT-EventRecorder.package/GTBasicRecorderEvent.class/instance/accessing - 
announcement info/imageHash.st
A GT-EventRecorder.package/GTBasicRecorderEvent.class/instance/accessing - 
announcement info/imageVersion.st
A GT-EventRecorder.package/GTBasicRecorderEvent.class/instance/accessing - 
announcement info/latestUpdate.st
A GT-EventRecorder.package/GTBasicRecorderEvent.class/instance/accessing - 
announcement info/sessionCreationTime.st
A 
GT-EventRecorder.package/GTBasicRecorderEvent.class/instance/accessing/hashForText_.st
A 
GT-EventRecorder.package/GTBasicRecorderEvent.class/instance/accessing/info.st
A 
GT-EventRecorder.package/GTBasicRecorderEvent.class/instance/accessing/infoAt_.st
A 
GT-EventRecorder.package/GTBasicRecorderEvent.class/instance/accessing/infoAt_ifAbsentPut_.st
A 
GT-EventRecorder.package/GTBasicRecorderEvent.class/instance/accessing/infoAt_ifAbsent_.st
A 
GT-EventRecorder.package/GTBasicRecorderEvent.class/instance/accessing/infoAt_ifPresent_ifAbsent_.st
A 
GT-EventRecorder.package/GTBasicRecorderEvent.class/instance/accessing/infoAt_putHashForText_.st
A 
GT-EventRecorder.package/GTBasicRecorderEvent.class/instance/accessing/infoAt_put_.st
A 
GT-EventRecorder.package/GTBasicRecorderEven

Re: [Pharo-dev] About the non-use of Announcer in Bloc

[Denis Kudriashov]

2016-08-31 10:10 GMT+02:00 Glenn Cavarlé :

> Hi all (I was out for some days),
>

Hi Glenn


>
> What i see is that Bloc EventRegistry:
> 1) is not thread safe (no mutex + #select:thenDo:)
> 2) doesn't allow handler removal from the handler list currently used in
> the
> thenDo: loop
> 3) is used specifically for a one-to-many communication (1 BlElement -> X
> handlers)
>
> The (1) doesn't seem to be a problem in Bloc during UI event processing
> because a new event handler, even if it is added from another thread, would
> be taken into account for the next event.
>

Problem that concurrent modification of OrderedCollection could just fail.
You will got debugger.


> I note that it is really not
> recommended (at all) to update an UI element elsewhere than in the UI
> thread
> and it is like that in all other UI frameworks i know.
>

Does it means that I should not subscribe on UI events from different (not
UI) processes?
How to do this if it is needed?
Should I always put subscription code into #defer: message (analogue)?
In that case what to do if I need to be sure that I really subscribe on
event and only after this continue my business logic process?


>
> The (2) is a very specific use case and i don't know if it is a real need
> in
> Bloc because this implies that an element has 2 handlers for the same event
> and one of them has to remove the other before it is executed and during
> the
> same event processing (maybe more a conception issue than a common use
> case...). In other cases, no problem for handler removal.
>

Very simple example: I want one shot handler for MouseMove to highlight
element once to see that my mouse was moved around.
So my handler will highlight target element and unsubscribe it immediately.
Problem that if you do it on OrderedCollection during iteration you could
skip one of the handlers. And probably some failures are also possible
(debugger again).

Of course you could say users do not do all of this. But what the
alternative? And if people will do this by "incident" it will be very
difficult to discover reasons.


>
> But maybe i miss some specific cases in (1) and in (2).
>
> To me, Announcer is really usefull and efficient when it is used as an
> event
> bus that can be shared between multiple objects.
> For instance, it seems to be useless to use an Announcer in NewValueHolder
> because it cannot be shared and it is only used internally to register
> handlers and to propagate only the same event (ValueChanged) to them. What
> is the gain of using a full featured Announcer in this case?
>

But in practice we never share any announcer instance. We always hide it
inside owner object. ValueHolder is not specific example.
Also ValueHolder is kind of active model for UI application which could be
shared between different views. And when it will be modified in one view
another view will be updated automatically.


>
> In Bloc the constraint is to propagate more than 2000 events/second without
> to decrease fps, so we cannot afford to x4 the time to process events even
> if Announcer is safer and better tested.
>

I wondering what the source of this constraint? Does Morphic follows it? I
guess not, but all Pharo works quite well with it.

Re: [Pharo-dev] Binary selector and special characters

[Eliot Miranda]

Oops.  No need to add a step method; the increment method already exists:


On Wed, Aug 31, 2016 at 9:12 AM, Eliot Miranda 
wrote:

>
>
> On Tue, Aug 30, 2016 at 8:14 AM, Nicolai Hess 
> wrote:
>
>>
>>
>> 2016-08-29 21:38 GMT+02:00 Thierry Goubier :
>>
>>> Le 29/08/2016 à 21:28, stepharo a écrit :
>>>


 Le 29/8/16 à 17:45, Thierry Goubier a écrit :

> Hi Stef,
>
> 2016-08-29 11:42 GMT+02:00 stepharo  >:
>
> Thierry
>
> If you have a better editor control even better :)
>
>>
>> Syntax wise, one could consider "" to be inside a comment (i.e.
>> do not split into two comments if encountered inside a comment,
>> as it is done now).
>>
> This one could be nice too :)
>
>
>  https://pharo.fogbugz.com/f/cases/19011/Integrate-two-doubl
> e-quotes-inside-comments
>
> I'll have the slice ready soon. Any comments on what that would mean
> regarding the Smalltalk commonly accepted syntax if that feature is
> integrated?
>
 It will break compatibility for people using it now we should raise the
 topic and lets a chance to people to discuss about it. We could check
 before publishing if code contain nested comments.

>>>
>>> Hum. The slice should parse anything legal Smalltalk; just that it may
>>> show less comments intervals (because in fact it will coalesce adjacent
>>> comments).
>>>
>>
>> Yes, I think the change for RBScanner is fine, it does not changes what
>> kind of comments are accepted, only how they are assigned to
>> the AST nodes (one vs. multiple comments).
>>
>> (BTW. do we have a function that would do the coalescing of intervals:
>>
>> (1 to:99) (100 to: 199) -> (1 to:199)
>>
>> ? )
>>
>
> Find attached something that works in Squeak 5
>
> For example, standard parse will say that:
>>>
>>> '"this ""test"' is a token with two comments, intervals 1 to: 7 and 8
>>> to: 13.
>>>
>>> The slice makes that a single comment:
>>>
>>> '"this ""test"' is a token with one comment, interval 1 to: 13.
>>>
>>> Now, this has probably no impact on parsing smalltalk code. But it
>>> changes a bit the language definition, so that's why I'd like comments on
>>> it.
>>>
>>> I think that I would use them only when developing.

>>>
>>> Up to you :)
>>>
>>> The most interesting is to have the correct comment/uncomment behavior
>>> in an editor... that one works independently and is quite cool.
>>>
>>> Thierry
>>>
>>> Stef


> Thierry
>

> _,,,^..^,,,_
> best, Eliot
>



-- 
_,,,^..^,,,_
best, Eliot


Interval-methods.st
Description: Binary data

Re: [Pharo-dev] About the non-use of Announcer in Bloc

[Glenn Cavarlé]

Hi all (I was out for some days),

What i see is that Bloc EventRegistry:
1) is not thread safe (no mutex + #select:thenDo:)
2) doesn't allow handler removal from the handler list currently used in the
thenDo: loop
3) is used specifically for a one-to-many communication (1 BlElement -> X
handlers)
 
The (1) doesn't seem to be a problem in Bloc during UI event processing
because a new event handler, even if it is added from another thread, would
be taken into account for the next event. I note that it is really not
recommended (at all) to update an UI element elsewhere than in the UI thread
and it is like that in all other UI frameworks i know.

The (2) is a very specific use case and i don't know if it is a real need in
Bloc because this implies that an element has 2 handlers for the same event
and one of them has to remove the other before it is executed and during the
same event processing (maybe more a conception issue than a common use
case...). In other cases, no problem for handler removal.

But maybe i miss some specific cases in (1) and in (2).

To me, Announcer is really usefull and efficient when it is used as an event
bus that can be shared between multiple objects.
For instance, it seems to be useless to use an Announcer in NewValueHolder
because it cannot be shared and it is only used internally to register
handlers and to propagate only the same event (ValueChanged) to them. What
is the gain of using a full featured Announcer in this case?

In Bloc the constraint is to propagate more than 2000 events/second without
to decrease fps, so we cannot afford to x4 the time to process events even
if Announcer is safer and better tested.

Regards,
Glenn.



-
Glenn Cavarlé
--
View this message in context: 
http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008p4913305.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Binary selector and special characters

[Eliot Miranda]

On Tue, Aug 30, 2016 at 8:14 AM, Nicolai Hess  wrote:

>
>
> 2016-08-29 21:38 GMT+02:00 Thierry Goubier :
>
>> Le 29/08/2016 à 21:28, stepharo a écrit :
>>
>>>
>>>
>>> Le 29/8/16 à 17:45, Thierry Goubier a écrit :
>>>
 Hi Stef,

 2016-08-29 11:42 GMT+02:00 stepharo >>> >:

 Thierry

 If you have a better editor control even better :)

>
> Syntax wise, one could consider "" to be inside a comment (i.e.
> do not split into two comments if encountered inside a comment,
> as it is done now).
>
 This one could be nice too :)


  https://pharo.fogbugz.com/f/cases/19011/Integrate-two-doubl
 e-quotes-inside-comments

 I'll have the slice ready soon. Any comments on what that would mean
 regarding the Smalltalk commonly accepted syntax if that feature is
 integrated?

>>> It will break compatibility for people using it now we should raise the
>>> topic and lets a chance to people to discuss about it. We could check
>>> before publishing if code contain nested comments.
>>>
>>
>> Hum. The slice should parse anything legal Smalltalk; just that it may
>> show less comments intervals (because in fact it will coalesce adjacent
>> comments).
>>
>
> Yes, I think the change for RBScanner is fine, it does not changes what
> kind of comments are accepted, only how they are assigned to
> the AST nodes (one vs. multiple comments).
>
> (BTW. do we have a function that would do the coalescing of intervals:
>
> (1 to:99) (100 to: 199) -> (1 to:199)
>
> ? )
>

Find attached something that works in Squeak 5

For example, standard parse will say that:
>>
>> '"this ""test"' is a token with two comments, intervals 1 to: 7 and 8 to:
>> 13.
>>
>> The slice makes that a single comment:
>>
>> '"this ""test"' is a token with one comment, interval 1 to: 13.
>>
>> Now, this has probably no impact on parsing smalltalk code. But it
>> changes a bit the language definition, so that's why I'd like comments on
>> it.
>>
>> I think that I would use them only when developing.
>>>
>>
>> Up to you :)
>>
>> The most interesting is to have the correct comment/uncomment behavior in
>> an editor... that one works independently and is quite cool.
>>
>> Thierry
>>
>> Stef
>>>
>>>
 Thierry

>>>
_,,,^..^,,,_
best, Eliot


Interval-methods.st
Description: Binary data

Re: [Pharo-dev] Binary selector and special characters

[Eliot Miranda]

On Tue, Aug 30, 2016 at 8:14 AM, Nicolai Hess  wrote:

>
>
> 2016-08-29 21:38 GMT+02:00 Thierry Goubier :
>
>> Le 29/08/2016 à 21:28, stepharo a écrit :
>>
>>>
>>>
>>> Le 29/8/16 à 17:45, Thierry Goubier a écrit :
>>>
 Hi Stef,

 2016-08-29 11:42 GMT+02:00 stepharo >>> >:

 Thierry

 If you have a better editor control even better :)

>
> Syntax wise, one could consider "" to be inside a comment (i.e.
> do not split into two comments if encountered inside a comment,
> as it is done now).
>
 This one could be nice too :)


  https://pharo.fogbugz.com/f/cases/19011/Integrate-two-doubl
 e-quotes-inside-comments

 I'll have the slice ready soon. Any comments on what that would mean
 regarding the Smalltalk commonly accepted syntax if that feature is
 integrated?

>>> It will break compatibility for people using it now we should raise the
>>> topic and lets a chance to people to discuss about it. We could check
>>> before publishing if code contain nested comments.
>>>
>>
>> Hum. The slice should parse anything legal Smalltalk; just that it may
>> show less comments intervals (because in fact it will coalesce adjacent
>> comments).
>>
>
> Yes, I think the change for RBScanner is fine, it does not changes what
> kind of comments are accepted, only how they are assigned to
> the AST nodes (one vs. multiple comments).
>
> (BTW. do we have a function that would do the coalescing of intervals:
>
> (1 to:99) (100 to: 199) -> (1 to:199)
>
> ? )
>

Specialize #, in Interval to check.  Right now #, will answer an Array, but
it would be easy to special-case.


>
>
>
>>
>> For example, standard parse will say that:
>>
>> '"this ""test"' is a token with two comments, intervals 1 to: 7 and 8 to:
>> 13.
>>
>> The slice makes that a single comment:
>>
>> '"this ""test"' is a token with one comment, interval 1 to: 13.
>>
>> Now, this has probably no impact on parsing smalltalk code. But it
>> changes a bit the language definition, so that's why I'd like comments on
>> it.
>>
>> I think that I would use them only when developing.
>>>
>>
>> Up to you :)
>>
>> The most interesting is to have the correct comment/uncomment behavior in
>> an editor... that one works independently and is quite cool.
>>
>> Thierry
>>
>> Stef
>>>
>>>
 Thierry


>>>
>>
>>
>


-- 
_,,,^..^,,,_
best, Eliot