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

[Norbert Hartl]

> Am 30.08.2016 um 06:38 schrieb Stephan Eggermont :
> 
> On 29/08/16 22:37, Denis Kudriashov wrote:
>> It looks quite safe to not check anything because subscription items are
>> instances of AnnouncementSubscription which are created internally
>> inside Announcer during subscription
> 
> We should probably do something special for 0 and 1 subscriptions.
> 
I think for the 0 case we should think about instantiating the 
SubscriptionRegistry lazily. This would also mitigate the effect that if a lot 
of announcers are created they create only a single object instead of two until 
used. Of course this depends on the probability of having a lot of announcers 
where only a few are used.
The #announce: method looks like it has been lazy before.

Announcer>>#announce: anAnnouncement

| announcement |
announcement := anAnnouncement asAnnouncement.  
registry ifNotNil: [
registry deliver: announcement
].
^ announcement

checks for #ifNotNil: but registry is created in #initialize. So #ifNotEmpty: 
would be right here but #deliver: checks that, too.

For the 1 case we could store a single subscription in the registry field. Both 
subscription and registry have the #deliver: method so this would work out of 
the box. We could just dispatch the method. 

So without having measured it myself it could be good if

- registry is nil if no subscribers are present. With nil checks the Announcer 
code could go fast
- registry is a subscription in case of 1 subscriber. No need for 
#subscriptionsHandling: because check is directly on the subscription for 
#handlesAnnouncement: This should save some cycles and the creation of 
intermediate collections. With not using the SubscriptionRegistry there is also 
no #critical: section saving the creation of one.
- registry is SubscriptionRegistry in case of >1 subscribers

my two cents,

Norbert

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

[stepharo]

Le 29/8/16 à 21:37, Tudor Girba a écrit :

Hi Denis,

Thanks a lot for this analysis!

In summary, the Bloc events are faster because:
1. they store the subscriptions in OrderedCollection instead of IdentitySet. 
This is likely something we can improve in Announcements.
2. they are unsafe.

For 1., the only reason I can think of is to prevent the user to register twice 
the same object by mistake. I think this is an optimization that should be the 
responsibility of the user.

It depends of the contract.
Since we want to have a solid architecture then it should not be the 
responsibility of the client to me.





For 2. the question is if Bloc really does not need the mutex.

Cheers,
Doru




On Aug 29, 2016, at 6:36 PM, Denis Kudriashov  wrote:

And expenses to deliver announcement caused also by protection and usage of 
IdentitySet.
Also in announcements we first collect all subscriptions with interest to 
separate collection and only after we iterate and process given announcement.

But in Bloc you use #select:thenDo: method instead. It is unsafe because event 
handlers can be modified during delivering (by producing new subscriptions or 
by unsubscribing inside handlers).

So if you want to address it (and I sure you do) it will lead to same code and 
performance of announcements.




2016-08-29 18:05 GMT+02:00 Denis Kudriashov :
Thank's.
I try tests for subscribing and what I found is:

Main problem that subscriptions inside SubscriptionRegistry are managed as 
IdentitySet which of cause much slower for addition then OrderedCollection. We 
probably could use OrderedCollection here because items are always created on 
fly and identitySet has no sense.

Another problem is access protection by mutex (semaphore) which make it 3 times 
slower.

So with OrderedCollection and disabled mutex performance for subscribing is 
same.

I pretty sure that protection is required for Block handlers too.

2016-08-29 17:18 GMT+02:00 Glenn Cavarlé :
Ha...  tag doesn't work...

You can load Bloc and show the tests using this script:
Gofer it
 smalltalkhubUser: 'Pharo' project: 'Bloc';
 configuration;
 loadDevelopment.
Gofer it
 smalltalkhubUser: 'Pharo' project: 'Bloc';
 package: 'Bloc-Tests';
 load.
BlAnnouncerVsBlEventRegistryTest browse




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




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

"Every successful trip needs a suitable vehicle."

Re: [Pharo-dev] wish for Iceberg

[stepharo]

My important wish for Iceberg is managing Pull Request.

Now I think that we should let nicolas release a version before 
bombarding him about features.



Le 29/8/16 à 22:11, Alexandre Bergel a écrit :

Hi!

It would be great to be able to save the repositories on the disk, somewhere. 
And to not have to type them all the time.

Also, if I install a git repository, I would like to be able to commit / push 
after modifying it.

Cheers,
Alexandre

Re: [Pharo-dev] [Moose-dev] [ann] pillar support in gtinspector

[stepharo]

Le 29/8/16 à 21:47, Yuriy Tymchuk a écrit :


On 29 Aug 2016, at 21:41, Tudor Girba > wrote:


Hi,

I updated the Pillar support in GTInspector. Some of the extensions 
already exist in the default Pillar #development version. If you want 
to play with the full support, you can load it like this:


Gofer new
smalltalkhubUser: 'Moose' project: 'PetitParser';
package: 'PetitAnalyzer';
package: 'PetitIndent';
package: 'PetitIslands';
smalltalkhubUser: 'Moose' project: 'GToolkit';
package: 'GT-InspectorExtensions-Pillar';
load

Then you can just inspect a book folder and you get this:




Cool!



I did not integrate this in the main Pillar yet because this is an 
older implementation based on a limited island parser. As now Pillar 
has a full parser based on PetitParser, the next step is to move the 
highlighting logic to use this parser instead of the island parser. 
From my measurements, the speed of the two parsers is about the same, 
so from a user perspective there will be not much changes.


It pains me that we are editing Pillar in outside tools, and now we 
should no longer have to do that. Of course, this is not the most 
ideal tool support for Pillar but I think it is a reasonable start.


To make things sadder: when I need to write some short “richish" I’m 
using markdown instead for pillar because in ATOM I can open the 
rendered version of my document that will update while i type (and 
will display images and so on). It could be nice to have the same 
functionality in Pharo, but I’m really busy with improving other 
parts. Additionally I’m not sure that it makes sense to reimplement 
rich text editor in Pharo.


It does. We want a real editor in Pharo.




Uko



Cheers,
Doru


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

"Problem solving should be focused on describing
the problem in a way that makes the solution obvious."





___
Moose-dev mailing list
moose-...@list.inf.unibe.ch 
https://www.list.inf.unibe.ch/listinfo/moose-dev

Re: [Pharo-dev] About Pharo 60

[stepharo]

Additionally I would like to see:

  - investigation in the Win Pharo VM for being able to run again as 
a Windows Service
(as it was possible for Squeak) to be able to easily provide, 
deploy and administrate a web

app on Windows

Definitively. Thanks for mentionning it. It will be done by PharoPro :)


  - image size management under control (as Philip already suggested)

  - better support for REST based systems (as Philip already suggested)
Can you be clearer? Because I thought that Seaside-REST was good and you 
can apply to non Seaside Application.

Then there is Teapot.
As Pharo core I do not see why Zinc is not enough. Now fr Pharo Pro I 
could see.


  - modern "Material style" UI (as Philip already suggested) but 
additionally with

better out of the box Spec support and examples for regular widgets
(Accordion, draggable Toolbars, calendar widget, date/time 
picker, ...)


  - clear rules to not accept undocumented classes/packages in the image
And a clear separation in packages between CORE/BASE stuff and 
TESTS on top.


Tests are already separated. Do you have some places where this is not 
the case?
Because TEST are usually only for development and for 
production/deployment of an app

TESTS usually should be thrown out.

Christmas list would include:
  - 64 Bit support

This is not a christmas list. It should be threr for September.



  - an out of the box Pharo Pi VM + image on the website

Bye
T.

Re: [Pharo-dev] wish for Iceberg

[Thierry Goubier]

Hi Nicolas,

Le 30/08/2016 à 01:18, Nicolas Passerini a écrit :



On Mon, Aug 29, 2016 at 10:11 PM, Alexandre Bergel
mailto:alexandre.ber...@me.com>> wrote:

Hi!

It would be great to be able to save the repositories on the disk,
somewhere. And to not have to type them all the time.


You're right, this is already in my backlog.
This is good feedback because now I can prioritize it better.



Also, if I install a git repository, I would like to be able to
commit / push after modifying it.

This is a bit more difficult, because (if I understand what you mean)
you have a git repo that you probably downloaded with Gofer or
Metacello. So Iceberg can not use it for committing/pushing (because it
is not a real git repo).


Why? If you integrate Iceberg like GitFileTree is (or reuse GitFileTree 
urls), then Metacello or Gofer will download (clone) git repositories 
and Iceberg should be able to work with them.


Now, if in your sentence, I replace git by github (as in Metacello 
github:// urls), then it makes sense, yes.


Thierry


I have been talking with Dale and Cristophe, so
that Metacello and Cargo will use Iceberg for downloading git repos...
so you will not have that problem any more. Still, it might be a while
until those changes are integrated in Metacello (I think).
So in the meantime I can build a tool to convert a git
metacello-downloaded MCRepository to an Iceberg repository in a simple
way. Do you think it would be useful?

[Pharo-dev] [SO] X-509 certificates

[Max Leske]

http://stackoverflow.com/questions/39210105/x-509-certificate-operations-with-pharo-smalltalk

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

[Stephan Eggermont]

On 29/08/16 22:37, Denis Kudriashov wrote:

It looks quite safe to not check anything because subscription items are
instances of AnnouncementSubscription which are created internally
inside Announcer during subscription


We should probably do something special for 0 and 1 subscriptions.

Stephan

Re: [Pharo-dev] IceBerg and push for projects vs packages

[Dale Henrichs]

On 8/29/16 8:12 AM, Esteban A. Maringolo wrote:

2016-08-29 9:12 GMT-03:00 Serge Stinckwich :

On Mon, Aug 29, 2016 at 2:08 PM, Esteban Lorenzano  wrote:

On 29 Aug 2016, at 14:04, Serge Stinckwich  wrote:

On Mon, Aug 29, 2016 at 10:52 AM, Nicolas Passerini
 wrote:

Well, I am not sure if this has to do with Iceberg itself, because Iceberg
does nothing with dependencies.

But I am not sure that a ConfigurationOfXXX really has information of only
one package. Normally you will have only one configuration for each project,
am I wrong?
Then the configuration specifies (among other stuff) dependencies between
the parts (packages) of your project... I think this is right.
If you depend in another project, then you should not depend in specific
packages but in another configuration.

With the Iceberg tool, you can load or unload packages.
How it will works if the dependencies are not loaded before ?

AFAIK, this is not iceberg concern… this is a work for metacello (or cargo).

Yes you are right, but when you load a package from Iceberg, the
dependencies should be loaded at the same time I guess.

No, they shouldn't. Because Iceberg, AFAIU, is for SCM, and Metacello
for dependency management. A proper package manager (Cargo?) should
coordinate artifacts of both.




Christophe and I are talking about the fact that there is overlap 
between Cargo and Metacello with regards to dependency management ... 
We'll see how things evolve ...


Dale

Re: [Pharo-dev] IceBerg and push for projects vs packages

[Nicolas Passerini]

>
> >>> With the Iceberg tool, you can load or unload packages.
> >>> How it will works if the dependencies are not loaded before ?
> >>
> >> AFAIK, this is not iceberg concern… this is a work for metacello (or
> cargo).
> >
> > Yes you are right, but when you load a package from Iceberg, the
> > dependencies should be loaded at the same time I guess.
>
> No, they shouldn't. Because Iceberg, AFAIU, is for SCM, and Metacello
> for dependency management. A proper package manager (Cargo?) should
> coordinate artifacts of both.
>
>
> I think I agree with both Estebans, I hope that Metacello/Cargo will use
Iceberg to load packages, but it should be their responsibility to decide
which packages and versions to load.

Re: [Pharo-dev] wish for Iceberg

[Nicolas Passerini]

On Mon, Aug 29, 2016 at 10:11 PM, Alexandre Bergel 
wrote:

> Hi!
>
> It would be great to be able to save the repositories on the disk,
> somewhere. And to not have to type them all the time.
>

You're right, this is already in my backlog.
This is good feedback because now I can prioritize it better.


>
> Also, if I install a git repository, I would like to be able to commit /
> push after modifying it.
>
> This is a bit more difficult, because (if I understand what you mean) you
have a git repo that you probably downloaded with Gofer or Metacello. So
Iceberg can not use it for committing/pushing (because it is not a real git
repo). I have been talking with Dale and Cristophe, so that Metacello and
Cargo will use Iceberg for downloading git repos... so you will not have
that problem any more. Still, it might be a while until those changes are
integrated in Metacello (I think).
So in the meantime I can build a tool to convert a git metacello-downloaded
MCRepository to an Iceberg repository in a simple way. Do you think it
would be useful?

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

[Tudor Girba]

> On Aug 29, 2016, at 10:37 PM, Denis Kudriashov  wrote:
> 
> 
> 2016-08-29 21:50 GMT+02:00 Yuriy Tymchuk :
> > For 1., the only reason I can think of is to prevent the user to register 
> > twice the same object by mistake. I think this is an optimization that 
> > should be the responsibility of the user.
> 
> Alternatively we may use OrderedCollection and just check if it includes the 
> subscription before adding. I think that more events are fired than clients 
> are subscribed per a period of time
> 
> 
> It looks quite safe to not check anything because subscription items are 
> instances of AnnouncementSubscription which are created internally inside 
> Announcer during subscription

+1

Doru



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

"Presenting is storytelling."

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

[Denis Kudriashov]

2016-08-29 21:50 GMT+02:00 Yuriy Tymchuk :

> > For 1., the only reason I can think of is to prevent the user to
> register twice the same object by mistake. I think this is an optimization
> that should be the responsibility of the user.
>
> Alternatively we may use OrderedCollection and just check if it includes
> the subscription before adding. I think that more events are fired than
> clients are subscribed per a period of time
>
>
It looks quite safe to not check anything because subscription items are
instances of AnnouncementSubscription which are created internally inside
Announcer during subscription

[Pharo-dev] wish for Iceberg

[Alexandre Bergel]

Hi!

It would be great to be able to save the repositories on the disk, somewhere. 
And to not have to type them all the time.

Also, if I install a git repository, I would like to be able to commit / push 
after modifying it. 

Cheers,
Alexandre

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

[Yuriy Tymchuk]

> On 29 Aug 2016, at 21:37, Tudor Girba  wrote:
> 
> Hi Denis,
> 
> Thanks a lot for this analysis!
> 
> In summary, the Bloc events are faster because:
> 1. they store the subscriptions in OrderedCollection instead of IdentitySet. 
> This is likely something we can improve in Announcements.
> 2. they are unsafe.
> 
> For 1., the only reason I can think of is to prevent the user to register 
> twice the same object by mistake. I think this is an optimization that should 
> be the responsibility of the user.

Alternatively we may use OrderedCollection and just check if it includes the 
subscription before adding. I think that more events are fired than clients are 
subscribed per a period of time

Uko

> 
> For 2. the question is if Bloc really does not need the mutex.
> 
> Cheers,
> Doru
> 
> 
> 
>> On Aug 29, 2016, at 6:36 PM, Denis Kudriashov  wrote:
>> 
>> And expenses to deliver announcement caused also by protection and usage of 
>> IdentitySet.
>> Also in announcements we first collect all subscriptions with interest to 
>> separate collection and only after we iterate and process given announcement.
>> 
>> But in Bloc you use #select:thenDo: method instead. It is unsafe because 
>> event handlers can be modified during delivering (by producing new 
>> subscriptions or by unsubscribing inside handlers). 
>> 
>> So if you want to address it (and I sure you do) it will lead to same code 
>> and performance of announcements. 
>> 
>> 
>> 
>> 
>> 2016-08-29 18:05 GMT+02:00 Denis Kudriashov :
>> Thank's. 
>> I try tests for subscribing and what I found is:
>> 
>> Main problem that subscriptions inside SubscriptionRegistry are managed as 
>> IdentitySet which of cause much slower for addition then OrderedCollection. 
>> We probably could use OrderedCollection here because items are always 
>> created on fly and identitySet has no sense.
>> 
>> Another problem is access protection by mutex (semaphore) which make it 3 
>> times slower. 
>> 
>> So with OrderedCollection and disabled mutex performance for subscribing is 
>> same.
>> 
>> I pretty sure that protection is required for Block handlers too. 
>> 
>> 2016-08-29 17:18 GMT+02:00 Glenn Cavarlé :
>> Ha...  tag doesn't work...
>> 
>> You can load Bloc and show the tests using this script:
>> Gofer it
>>smalltalkhubUser: 'Pharo' project: 'Bloc';
>>configuration;
>>loadDevelopment.
>> Gofer it
>>smalltalkhubUser: 'Pharo' project: 'Bloc';
>>package: 'Bloc-Tests';
>>load.
>> BlAnnouncerVsBlEventRegistryTest browse
>> 
>> 
>> 
>> 
>> -
>> Glenn Cavarlé
>> --
>> View this message in context: 
>> http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008p4913088.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>> 
>> 
>> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Every successful trip needs a suitable vehicle."
> 
> 
> 
> 
> 
> 

Re: [Pharo-dev] [Moose-dev] [ann] pillar support in gtinspector

[Yuriy Tymchuk]

> On 29 Aug 2016, at 21:41, Tudor Girba  wrote:
> 
> Hi,
> 
> I updated the Pillar support in GTInspector. Some of the extensions already 
> exist in the default Pillar #development version. If you want to play with 
> the full support, you can load it like this:
> 
> Gofer new
>   smalltalkhubUser: 'Moose' project: 'PetitParser';
>   package: 'PetitAnalyzer';
>   package: 'PetitIndent';
>   package: 'PetitIslands';
>   smalltalkhubUser: 'Moose' project: 'GToolkit';
>   package: 'GT-InspectorExtensions-Pillar';
>   load
> 
> Then you can just inspect a book folder and you get this:
> 
> 

Cool!

> 
> I did not integrate this in the main Pillar yet because this is an older 
> implementation based on a limited island parser. As now Pillar has a full 
> parser based on PetitParser, the next step is to move the highlighting logic 
> to use this parser instead of the island parser. From my measurements, the 
> speed of the two parsers is about the same, so from a user perspective there 
> will be not much changes.
> 
> It pains me that we are editing Pillar in outside tools, and now we should no 
> longer have to do that. Of course, this is not the most ideal tool support 
> for Pillar but I think it is a reasonable start.

To make things sadder: when I need to write some short “richish" I’m using 
markdown instead for pillar because in ATOM I can open the rendered version of 
my document that will update while i type (and will display images and so on). 
It could be nice to have the same functionality in Pharo, but I’m really busy 
with improving other parts. Additionally I’m not sure that it makes sense to 
reimplement rich text editor in Pharo.

Uko

> 
> Cheers,
> Doru
> 
> 
> --
> www.tudorgirba.com 
> www.feenk.com
> 
> "Problem solving should be focused on describing
> the problem in a way that makes the solution obvious."
> 
> 
> 
> 
> 
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

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

[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 mailto:steph...@free.fr>>:

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


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

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

[Tudor Girba]

Hi Denis,

Thanks a lot for this analysis!

In summary, the Bloc events are faster because:
1. they store the subscriptions in OrderedCollection instead of IdentitySet. 
This is likely something we can improve in Announcements.
2. they are unsafe.

For 1., the only reason I can think of is to prevent the user to register twice 
the same object by mistake. I think this is an optimization that should be the 
responsibility of the user.

For 2. the question is if Bloc really does not need the mutex.

Cheers,
Doru



> On Aug 29, 2016, at 6:36 PM, Denis Kudriashov  wrote:
> 
> And expenses to deliver announcement caused also by protection and usage of 
> IdentitySet.
> Also in announcements we first collect all subscriptions with interest to 
> separate collection and only after we iterate and process given announcement.
> 
> But in Bloc you use #select:thenDo: method instead. It is unsafe because 
> event handlers can be modified during delivering (by producing new 
> subscriptions or by unsubscribing inside handlers). 
> 
> So if you want to address it (and I sure you do) it will lead to same code 
> and performance of announcements. 
> 
> 
> 
> 
> 2016-08-29 18:05 GMT+02:00 Denis Kudriashov :
> Thank's. 
> I try tests for subscribing and what I found is:
> 
> Main problem that subscriptions inside SubscriptionRegistry are managed as 
> IdentitySet which of cause much slower for addition then OrderedCollection. 
> We probably could use OrderedCollection here because items are always created 
> on fly and identitySet has no sense.
> 
> Another problem is access protection by mutex (semaphore) which make it 3 
> times slower. 
> 
> So with OrderedCollection and disabled mutex performance for subscribing is 
> same.
> 
> I pretty sure that protection is required for Block handlers too. 
> 
> 2016-08-29 17:18 GMT+02:00 Glenn Cavarlé :
> Ha...  tag doesn't work...
> 
> You can load Bloc and show the tests using this script:
> Gofer it
> smalltalkhubUser: 'Pharo' project: 'Bloc';
> configuration;
> loadDevelopment.
> Gofer it
> smalltalkhubUser: 'Pharo' project: 'Bloc';
> package: 'Bloc-Tests';
> load.
> BlAnnouncerVsBlEventRegistryTest browse
> 
> 
> 
> 
> -
> Glenn Cavarlé
> --
> View this message in context: 
> http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008p4913088.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 
> 
> 

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

"Every successful trip needs a suitable vehicle."

Re: [Pharo-dev] About Pharo 60

[stepharo]

Thanks

we are currently brainstorming with esteban on the pharo pro offer and 
this is nice to have your feedback.


Stef


Le 28/8/16 à 15:33, Torsten Bergmann a écrit :

what are the points you are working on and that would deserve more focus and 
help from the community?

I once started with a refactored version of GetText, covered with tests and 
tools.
Code status I reached so far is here:

   http://www.smalltalkhub.com/#!/~TorstenBergmann/Gettext

Idea was to be lean, no dependency on Seaside or others and get a well 
documented easy to use I18N solution.
This would open up the possibility for more internationalized Pharo image and 
Pharo based apps. Would be nice
if this could be completed and become part of our infrastructure to get a wider 
audience and globally usable
applications.

Additionally I would like to see:

  - investigation in the Win Pharo VM for being able to run again as a Windows 
Service
(as it was possible for Squeak) to be able to easily provide, deploy and 
administrate a web
app on Windows

  - image size management under control (as Philip already suggested)

  - better support for REST based systems (as Philip already suggested)

  - modern "Material style" UI (as Philip already suggested) but additionally 
with
better out of the box Spec support and examples for regular widgets
(Accordion, draggable Toolbars, calendar widget, date/time picker, ...)

  - clear rules to not accept undocumented classes/packages in the image
And a clear separation in packages between CORE/BASE stuff and TESTS on top.
Because TEST are usually only for development and for production/deployment 
of an app
TESTS usually should be thrown out.

Christmas list would include:
  - 64 Bit support
  - an out of the box Pharo Pi VM + image on the website

Bye
T.

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

[stepharo]

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

I think that I would use them only when developing.

Stef



Thierry

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

[stepharo]

Hi henrik

thanks for your analysis. I always wanted to deeply understand the 
difference between announcements and a simple registry mechanism.


Now I'm too tired to think (yes I need to sleep a 9h25 :) but I will 
reread this mail when my brain is back .


stef

Le 29/8/16 à 00:54, Henrik Nergaard a écrit :

Probably from the use of critical (mutex), the way #subscriptionsHandling: is 
done, and that Announcer is built for X number of announcers and Y number of 
subscribers, which means that each announcement the announcer has to filter and 
find the correct subscribers.


| ann a |

ann := Announcer new.

ann when: Announcement do: [ :e ].
a := Announcement new.
[[ ann announce: a ] bench ] timeProfile

-

Other drawbacks to consider when using announcements:
Memory overhead from the Announcer object and each subscription.
Memory ownership, the announcement subscriptions will strongly reference the 
announcement target unless the announcement is weakly, which can lead to memory 
leakage especially if strong and weak subscriptions are mixed in certain 
situations (see the mailing list from around the release of Pharo 6). This also 
leads to code where the announcer is the one who owns the target (multiple 
times if there are different announcements),  which makes understanding who 
references what etc.. much harder to understand.
In many places the control/message flow, and the relationship between the 
different parts of a bigger object tends to become much more difficult to 
understand (For example Rubric).

Announcer usage shines when there is a need for a common place that X objects 
can communicate  Y messages to Z recipients without needing to know who sends 
what, or who wants to receive what (For example System Announcements).

Communication when only one Object "A" announces to another Object(s) "B", is 
better implemented as A referencing B, then B implements the necessary methods needed for this 
communication.

Best regards,
Henrik



-Original Message-
From: Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] On Behalf Of Glenn 
Cavarlé
Sent: Sunday, August 28, 2016 9:11 PM
To: pharo-dev@lists.pharo.org
Subject: [Pharo-dev] About the non-use of Announcer in Bloc

Hi all,
Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of 
Announcer in Bloc.
I made some test cases in Bloc-Tests to compare performances between Announcer 
and BlEventRegistry.
The result is that Announcer is at least 5x slower in all tested cases.
Bloc has only specific needs about event dispatching,  the first one is the 
efficiency during event propagation.
It may be interesting to investigate why Announcer is slower and also what are 
the uncovered cases in BlEventRegistry.
So, i'm interested in continuing our discussion about that.

Regards,
Glenn.



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

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

[stepharo]

Thanks Glenn!!!


Hi all,
Doru, Stephan, Norbert, Denis and me spoke at ESUG about the non-use of
Announcer in Bloc.
I made some test cases in Bloc-Tests to compare performances between
Announcer and BlEventRegistry.
The result is that Announcer is at least 5x slower in all tested cases.
Bloc has only specific needs about event dispatching,  the first one is the
efficiency during event propagation.
It may be interesting to investigate why Announcer is slower and also what
are the uncovered cases in BlEventRegistry.
So, i'm interested in continuing our discussion about that.

Regards,
Glenn.



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

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

[Denis Kudriashov]

And now question is why SubscriptionRegistry manages subscriptions as
IdentitySet instead of OrderedCollection?

2016-08-29 18:36 GMT+02:00 Denis Kudriashov :

> And expenses to deliver announcement caused also by protection and usage
> of IdentitySet.
> Also in announcements we first collect all subscriptions with interest to
> separate collection and only after we iterate and process given
> announcement.
>
> But in Bloc you use #select:thenDo: method instead. It is unsafe because
> event handlers can be modified during delivering (by producing new
> subscriptions or by unsubscribing inside handlers).
>
> So if you want to address it (and I sure you do) it will lead to same code
> and performance of announcements.
>
>
>
>
> 2016-08-29 18:05 GMT+02:00 Denis Kudriashov :
>
>> Thank's.
>> I try tests for subscribing and what I found is:
>>
>> Main problem that subscriptions inside SubscriptionRegistry are managed
>> as IdentitySet which of cause much slower for addition then
>> OrderedCollection. We probably could use OrderedCollection here because
>> items are always created on fly and identitySet has no sense.
>>
>> Another problem is access protection by mutex (semaphore) which make it 3
>> times slower.
>>
>> So with OrderedCollection and disabled mutex performance for subscribing
>> is same.
>>
>> I pretty sure that protection is required for Block handlers too.
>>
>> 2016-08-29 17:18 GMT+02:00 Glenn Cavarlé :
>>
>>> Ha...  tag doesn't work...
>>>
>>> You can load Bloc and show the tests using this script:
>>> Gofer it
>>> smalltalkhubUser: 'Pharo' project: 'Bloc';
>>> configuration;
>>> loadDevelopment.
>>> Gofer it
>>> smalltalkhubUser: 'Pharo' project: 'Bloc';
>>> package: 'Bloc-Tests';
>>> load.
>>> BlAnnouncerVsBlEventRegistryTest browse
>>>
>>>
>>>
>>>
>>> -
>>> Glenn Cavarlé
>>> --
>>> View this message in context: http://forum.world.st/About-th
>>> e-non-use-of-Announcer-in-Bloc-tp4913008p4913088.html
>>> Sent from the Pharo Smalltalk Developers mailing list archive at
>>> Nabble.com.
>>>
>>>
>>
>

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

[Denis Kudriashov]

And expenses to deliver announcement caused also by protection and usage of
IdentitySet.
Also in announcements we first collect all subscriptions with interest to
separate collection and only after we iterate and process given
announcement.

But in Bloc you use #select:thenDo: method instead. It is unsafe because
event handlers can be modified during delivering (by producing new
subscriptions or by unsubscribing inside handlers).

So if you want to address it (and I sure you do) it will lead to same code
and performance of announcements.




2016-08-29 18:05 GMT+02:00 Denis Kudriashov :

> Thank's.
> I try tests for subscribing and what I found is:
>
> Main problem that subscriptions inside SubscriptionRegistry are managed as
> IdentitySet which of cause much slower for addition then OrderedCollection.
> We probably could use OrderedCollection here because items are always
> created on fly and identitySet has no sense.
>
> Another problem is access protection by mutex (semaphore) which make it 3
> times slower.
>
> So with OrderedCollection and disabled mutex performance for subscribing
> is same.
>
> I pretty sure that protection is required for Block handlers too.
>
> 2016-08-29 17:18 GMT+02:00 Glenn Cavarlé :
>
>> Ha...  tag doesn't work...
>>
>> You can load Bloc and show the tests using this script:
>> Gofer it
>> smalltalkhubUser: 'Pharo' project: 'Bloc';
>> configuration;
>> loadDevelopment.
>> Gofer it
>> smalltalkhubUser: 'Pharo' project: 'Bloc';
>> package: 'Bloc-Tests';
>> load.
>> BlAnnouncerVsBlEventRegistryTest browse
>>
>>
>>
>>
>> -
>> Glenn Cavarlé
>> --
>> View this message in context: http://forum.world.st/About-th
>> e-non-use-of-Announcer-in-Bloc-tp4913008p4913088.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>>
>>
>

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

[Denis Kudriashov]

Thank's.
I try tests for subscribing and what I found is:

Main problem that subscriptions inside SubscriptionRegistry are managed as
IdentitySet which of cause much slower for addition then OrderedCollection.
We probably could use OrderedCollection here because items are always
created on fly and identitySet has no sense.

Another problem is access protection by mutex (semaphore) which make it 3
times slower.

So with OrderedCollection and disabled mutex performance for subscribing is
same.

I pretty sure that protection is required for Block handlers too.

2016-08-29 17:18 GMT+02:00 Glenn Cavarlé :

> Ha...  tag doesn't work...
>
> You can load Bloc and show the tests using this script:
> Gofer it
> smalltalkhubUser: 'Pharo' project: 'Bloc';
> configuration;
> loadDevelopment.
> Gofer it
> smalltalkhubUser: 'Pharo' project: 'Bloc';
> package: 'Bloc-Tests';
> load.
> BlAnnouncerVsBlEventRegistryTest browse
>
>
>
>
> -
> Glenn Cavarlé
> --
> View this message in context: http://forum.world.st/About-
> the-non-use-of-Announcer-in-Bloc-tp4913008p4913088.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

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

[Thierry Goubier]

2016-08-29 13:24 GMT+02:00 Peter Uhnák :

>
>
> On Mon, Aug 29, 2016 at 11:42 AM, stepharo  wrote:
>
>> 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 :)
>>
>
> This would be also consistent with how single quotes are handled in a
> string, which would make it doublenice. :)
>

Implementing it means looking at how strings are scanned :)

Thierry


>
> Peter
>

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

[Thierry Goubier]

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

Thierry

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

[Glenn Cavarlé]

Ha...  tag doesn't work...

You can load Bloc and show the tests using this script: 
Gofer it 
smalltalkhubUser: 'Pharo' project: 'Bloc';
configuration;
loadDevelopment.
Gofer it
smalltalkhubUser: 'Pharo' project: 'Bloc';
package: 'Bloc-Tests';
load.
BlAnnouncerVsBlEventRegistryTest browse




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

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

[Tudor Girba]

Hi,

You can find the current Bloc image here:
https://ci.inria.fr/moose/job/bloc/lastSuccessfulBuild/artifact/bloc.zip

Cheers,
Doru


> On Aug 29, 2016, at 5:10 PM, Denis Kudriashov  wrote:
> 
> And could you write current repository?
> 
> 2016-08-29 16:31 GMT+02:00 Glenn Cavarlé :
> You can load Bloc and show the tests using this script:
> 
> 
> 
> 
> -
> Glenn Cavarlé
> --
> View this message in context: 
> http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008p4913079.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 
> 

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

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

Re: [Pharo-dev] IceBerg and push for projects vs packages

[Esteban A. Maringolo]

2016-08-29 9:12 GMT-03:00 Serge Stinckwich :
> On Mon, Aug 29, 2016 at 2:08 PM, Esteban Lorenzano  
> wrote:
>>
>>> On 29 Aug 2016, at 14:04, Serge Stinckwich  
>>> wrote:
>>>
>>> On Mon, Aug 29, 2016 at 10:52 AM, Nicolas Passerini
>>>  wrote:
 Well, I am not sure if this has to do with Iceberg itself, because Iceberg
 does nothing with dependencies.

 But I am not sure that a ConfigurationOfXXX really has information of only
 one package. Normally you will have only one configuration for each 
 project,
 am I wrong?
 Then the configuration specifies (among other stuff) dependencies between
 the parts (packages) of your project... I think this is right.
 If you depend in another project, then you should not depend in specific
 packages but in another configuration.
>>>
>>> With the Iceberg tool, you can load or unload packages.
>>> How it will works if the dependencies are not loaded before ?
>>
>> AFAIK, this is not iceberg concern… this is a work for metacello (or cargo).
>
> Yes you are right, but when you load a package from Iceberg, the
> dependencies should be loaded at the same time I guess.

No, they shouldn't. Because Iceberg, AFAIU, is for SCM, and Metacello
for dependency management. A proper package manager (Cargo?) should
coordinate artifacts of both.


Esteban A. Maringolo

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

[Denis Kudriashov]

And could you write current repository?

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

> You can load Bloc and show the tests using this script:
>
>
>
>
> -
> Glenn Cavarlé
> --
> View this message in context: http://forum.world.st/About-
> the-non-use-of-Announcer-in-Bloc-tp4913008p4913079.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] Shortcuts conflicts

[Tudor Girba]

Hi Cyril,

No problem. I am glad you found the solution.

Cheers,
Doru


> On Aug 29, 2016, at 4:24 PM, Cyril Ferlicot Delbecque 
>  wrote:
> 
> 
> 
> On 29/08/2016 16:14, Peter Uhnák wrote:
>> Make sure you are not getting screwed by startup scripts (since you are
>> already overriding the debugger shortcuts).
>> 
>> Peter
>> 
> 
> It was the problem :( I found it with the help of Andrei and he helped
> me to improve my script.
> 
> Sorry for the false alarm!
> 
> -- 
> Cyril Ferlicot
> 
> http://www.synectique.eu
> 
> 165 Avenue Bretagne
> Lille 59000 France
> 

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

"Reasonable is what we are accustomed with."

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

[Tudor Girba]

Hi,

And the script is? :)

Doru


> On Aug 29, 2016, at 4:31 PM, Glenn Cavarlé  wrote:
> 
> You can load Bloc and show the tests using this script:
> 
> 
> 
> 
> -
> Glenn Cavarlé
> --
> View this message in context: 
> http://forum.world.st/About-the-non-use-of-Announcer-in-Bloc-tp4913008p4913079.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 

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

"Every thing should have the right to be different."

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

[Glenn Cavarlé]

You can load Bloc and show the tests using this script:




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

Re: [Pharo-dev] Shortcuts conflicts

[Cyril Ferlicot Delbecque]

On 29/08/2016 16:14, Peter Uhnák wrote:
> Make sure you are not getting screwed by startup scripts (since you are
> already overriding the debugger shortcuts).
> 
> Peter
> 

It was the problem :( I found it with the help of Andrei and he helped
me to improve my script.

Sorry for the false alarm!

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] Shortcuts conflicts

[Tudor Girba]

Hi,

Could you please try to reproduce this in any of the images publicly available 
(e.g., Moose, Pharo)?

Cheers,
Doru


> On Aug 29, 2016, at 3:42 PM, Cyril Ferlicot Delbecque 
>  wrote:
> 
> 
> 
> On 29/08/2016 15:40, Nicolai Hess wrote:
>> I don't even know how you get this menu.
>> What pane is selected when you open this context menu?
>> 
> 
> I just did a right click on the source pane of the debugger
> 
> -- 
> Cyril Ferlicot
> 
> http://www.synectique.eu
> 
> 165 Avenue Bretagne
> Lille 59000 France
> 

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

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

Re: [Pharo-dev] Shortcuts conflicts

[Cyril Ferlicot Delbecque]

On 29/08/2016 15:40, Nicolai Hess wrote:
> I don't even know how you get this menu.
> What pane is selected when you open this context menu?
> 

I just did a right click on the source pane of the debugger

-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] Shortcuts conflicts

[Nicolai Hess]

2016-08-29 15:28 GMT+02:00 Cyril Ferlicot Delbecque <
cyril.ferli...@gmail.com>:

> Hi,
>
> I am the only one to find this screen weird?
>
> https://puu.sh/qSyo9/baa12ac902.png
>
> It's pretty annoying when I am debugging and that instead of an
> inspector I get the inheritance…
> Or when I change a method in the debugger, I want to paste a sentence (I
> know, copy/paste are evil but sometimes they can be useful) and I get
> the versions window…
>
> Could we find a way to improve that? :)
>

I don't even know how you get this menu.
What pane is selected when you open this context menu?


> --
> Cyril Ferlicot
>
> http://www.synectique.eu
>
> 165 Avenue Bretagne
> Lille 59000 France
>
>

[Pharo-dev] Shortcuts conflicts

[Cyril Ferlicot Delbecque]

Hi,

I am the only one to find this screen weird?

https://puu.sh/qSyo9/baa12ac902.png

It's pretty annoying when I am debugging and that instead of an
inspector I get the inheritance…
Or when I change a method in the debugger, I want to paste a sentence (I
know, copy/paste are evil but sometimes they can be useful) and I get
the versions window…

Could we find a way to improve that? :)
-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] IceBerg and push for projects vs packages

[Serge Stinckwich]

On Mon, Aug 29, 2016 at 2:08 PM, Esteban Lorenzano  wrote:
>
>> On 29 Aug 2016, at 14:04, Serge Stinckwich  
>> wrote:
>>
>> On Mon, Aug 29, 2016 at 10:52 AM, Nicolas Passerini
>>  wrote:
>>> Well, I am not sure if this has to do with Iceberg itself, because Iceberg
>>> does nothing with dependencies.
>>>
>>> But I am not sure that a ConfigurationOfXXX really has information of only
>>> one package. Normally you will have only one configuration for each project,
>>> am I wrong?
>>> Then the configuration specifies (among other stuff) dependencies between
>>> the parts (packages) of your project... I think this is right.
>>> If you depend in another project, then you should not depend in specific
>>> packages but in another configuration.
>>
>> With the Iceberg tool, you can load or unload packages.
>> How it will works if the dependencies are not loaded before ?
>
> AFAIK, this is not iceberg concern… this is a work for metacello (or cargo).

Yes you are right, but when you load a package from Iceberg, the
dependencies should be loaded at the same time I guess.

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

Re: [Pharo-dev] IceBerg and push for projects vs packages

[Esteban Lorenzano]

> On 29 Aug 2016, at 14:04, Serge Stinckwich  wrote:
> 
> On Mon, Aug 29, 2016 at 10:52 AM, Nicolas Passerini
>  wrote:
>> Well, I am not sure if this has to do with Iceberg itself, because Iceberg
>> does nothing with dependencies.
>> 
>> But I am not sure that a ConfigurationOfXXX really has information of only
>> one package. Normally you will have only one configuration for each project,
>> am I wrong?
>> Then the configuration specifies (among other stuff) dependencies between
>> the parts (packages) of your project... I think this is right.
>> If you depend in another project, then you should not depend in specific
>> packages but in another configuration.
> 
> With the Iceberg tool, you can load or unload packages.
> How it will works if the dependencies are not loaded before ?

AFAIK, this is not iceberg concern… this is a work for metacello (or cargo).

Esteban

> 
>> The problem here is that we are (at least Iceberg is) assuming a correlation
>> between project and repository, because in fact Iceberg handles
>> repositories. If a project would be spawn in several repositories, at least
>> now Iceberg can't do anything about it, it will treat them as independent
>> "projects". I am not sure about changing this logic in the near future, and
>> also we should think if that is not a Cargo/Metacello feature.
> 
> I never see a project spawn on many repo. I guess you can safely say
> that 1 project = 1 repo.
> 
> -- 
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://www.doesnotunderstand.org/
> 

Re: [Pharo-dev] IceBerg and push for projects vs packages

[Serge Stinckwich]

On Mon, Aug 29, 2016 at 10:52 AM, Nicolas Passerini
 wrote:
> Well, I am not sure if this has to do with Iceberg itself, because Iceberg
> does nothing with dependencies.
>
> But I am not sure that a ConfigurationOfXXX really has information of only
> one package. Normally you will have only one configuration for each project,
> am I wrong?
> Then the configuration specifies (among other stuff) dependencies between
> the parts (packages) of your project... I think this is right.
> If you depend in another project, then you should not depend in specific
> packages but in another configuration.

With the Iceberg tool, you can load or unload packages.
How it will works if the dependencies are not loaded before ?

> The problem here is that we are (at least Iceberg is) assuming a correlation
> between project and repository, because in fact Iceberg handles
> repositories. If a project would be spawn in several repositories, at least
> now Iceberg can't do anything about it, it will treat them as independent
> "projects". I am not sure about changing this logic in the near future, and
> also we should think if that is not a Cargo/Metacello feature.

I never see a project spawn on many repo. I guess you can safely say
that 1 project = 1 repo.

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

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

[Thierry Goubier]

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

> Thierry
>
> If you have a better editor control even better :)
>

What I did is yank that sort of behavior into independent commands that are
keymap-bound to an editor. A lot easier to customize " independently of ',
(, [.

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

And simple: probably just a line or two inside RBScanner.

Thierry

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

[Peter Uhnák]

On Mon, Aug 29, 2016 at 11:42 AM, stepharo  wrote:

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

This would be also consistent with how single quotes are handled in a
string, which would make it doublenice. :)

Peter

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

[Denis Kudriashov]

Hi

2016-08-29 8:25 GMT+02:00 Tudor Girba :

> Hi Glenn,
>
> Thanks a lot for this experiment. Could you send us the code snippet so
> people can play with it?
>

Or some links where to download image with Bloc-Tests

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

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

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

[Thierry Goubier]

2016-08-29 10:58 GMT+02:00 Thierry Goubier :

> Hi Stef,
>
> 2016-08-29 8:35 GMT+02:00 stepharo :
>
>> This is a really nice and important question.
>> I would really have a clear answer because it will make the system more
>> stable.
>>
>> If you can build an analysis and let us know it would be really great.
>>
>>
>> Something related but not on the same topic is that I would love to have
>> a syntax for nested comments.
>>
>> This is really annoying to have to uncomment parts when we have to
>> comment a large part. We discussed this back in 2007-2009 but we never did
>> it.
>>
>
> If your need is that (uncomment while commenting and the reverse), then
> the answer is not a syntax change, but a better comment/uncomment command
> in the editor.
>
> Now that you say that, I also have the issue. I'll have a try in
> AltBrowser if I can get the behavior you'd like.
>

That works, but:

- Single click select doesn't work very well (stops at the next double
quotes instead of the end double quote)

- The formatter likes to split double quotes (adding returns)

- Backporting that to a standard editor is a mess, because there is a need
to change the #enclose: method.

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

Thierry



>
> Thierry
>
>
>>
>>
>> Stef
>>
>>
>> Le 28/8/16 à 12:17, Nicolai Hess a écrit :
>>
>> Hi,
>>>
>>> where can I find a good reference about what characters are allowed as
>>> binary selectors (from old syntax definition) and what is nowadays
>>> allowed
>>> by the implementations.
>>>
>>> And whether the current set of allowed binaries selector includes some
>>> additions on
>>> purpose or if this is just a bug of the parser.
>>>
>>> From what I found out,  (Blue book and some other smalltalk syntax
>>> definitions)
>>> the current set of allowed characters includes the "special characters":
>>> $! $% $& $* $+ $, $- $/ $< $= $> $? $@ $\ $| $~
>>> (some implementation do not allow $@ and some calls $- not a special
>>> character
>>> but allowed as binary selector character)
>>>
>>> And this is what String>>#numArgs uses. Therefore
>>>
>>> '-' numArgs "->1".
>>> '!' numArgs "->1".
>>> And for example:
>>> '§' numArgs "-> -1 (the -1 is indicating "not even a valid selector")"
>>>
>>> But I am interested in the characters not called "special characters and
>>> not even in the range 0-126.
>>>
>>> The scanner allowes much more characters to be used as a selector name
>>> (From the scanners typeTable) :
>>>
>>> {Character value: 1 . Character value: 2 . Character value: 3 .
>>> Character value: 4 . Character value: 5 . Character value: 6 . Character
>>> value: 7 . Character backspace . Character value: 11 . Character value: 14
>>> . Character value: 15 . Character value: 16 . Character value: 17 .
>>> Character value: 18 . Character value: 19 . Character value: 20 . Character
>>> value: 21 . Character value: 22 . Character value: 23 . Character value: 24
>>> . Character value: 25 . Character value: 26 . Character escape . Character
>>> value: 28 . Character value: 29 . Character value: 30 . Character value: 31
>>> . $! . $% . $& . $* . $+ . $, . $- . $/ . $< . $= . $> . $? . $@ . $\ . $`
>>> . $~ . Character delete . $€ . $ . $‚ . $ƒ . $„ . $… . $† . $‡ . $ˆ . $‰ .
>>> $Š . $‹ . $Œ . $ . $Ž . $ . $ . $‘ . $’ . $“ . $” . $• . $– . $— . $˜ . $™
>>> . $š . $› . $œ . $ . $ž . $Ÿ . $  . $¡ . $¢ . $£ . $¤ . $¥ . $¦ . $§ . $¨ .
>>> $© . $« . $¬ . $­ . $® . $¯ . $° . $± . $² . $³ . $´ . $¶ . $· . $¸ . $¹ .
>>> $» . $¼ . $½ . $¾ . $¿ . $× . $÷}
>>>
>>> This means you can define a method with for example the name "÷".
>>>
>>> So , the question I want to ask. What do we want to allow as a binary
>>> selector (character).
>>> All that is nowadays "parseable" as binary selector, or only the set of
>>> "special characters"
>>> or something between both, and where to put this information, the "this
>>> is an allowed binary
>>> selector character" information?
>>>
>>> Thanks
>>> Nicolai
>>>
>>>
>>
>>
>

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

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

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

[Thierry Goubier]

Hi Stef,

2016-08-29 8:35 GMT+02:00 stepharo :

> This is a really nice and important question.
> I would really have a clear answer because it will make the system more
> stable.
>
> If you can build an analysis and let us know it would be really great.
>
>
> Something related but not on the same topic is that I would love to have a
> syntax for nested comments.
>
> This is really annoying to have to uncomment parts when we have to comment
> a large part. We discussed this back in 2007-2009 but we never did it.
>

If your need is that (uncomment while commenting and the reverse), then the
answer is not a syntax change, but a better comment/uncomment command in
the editor.

Now that you say that, I also have the issue. I'll have a try in AltBrowser
if I can get the behavior you'd like.

Thierry


>
>
> Stef
>
>
> Le 28/8/16 à 12:17, Nicolai Hess a écrit :
>
> Hi,
>>
>> where can I find a good reference about what characters are allowed as
>> binary selectors (from old syntax definition) and what is nowadays allowed
>> by the implementations.
>>
>> And whether the current set of allowed binaries selector includes some
>> additions on
>> purpose or if this is just a bug of the parser.
>>
>> From what I found out,  (Blue book and some other smalltalk syntax
>> definitions)
>> the current set of allowed characters includes the "special characters":
>> $! $% $& $* $+ $, $- $/ $< $= $> $? $@ $\ $| $~
>> (some implementation do not allow $@ and some calls $- not a special
>> character
>> but allowed as binary selector character)
>>
>> And this is what String>>#numArgs uses. Therefore
>>
>> '-' numArgs "->1".
>> '!' numArgs "->1".
>> And for example:
>> '§' numArgs "-> -1 (the -1 is indicating "not even a valid selector")"
>>
>> But I am interested in the characters not called "special characters and
>> not even in the range 0-126.
>>
>> The scanner allowes much more characters to be used as a selector name
>> (From the scanners typeTable) :
>>
>> {Character value: 1 . Character value: 2 . Character value: 3 . Character
>> value: 4 . Character value: 5 . Character value: 6 . Character value: 7 .
>> Character backspace . Character value: 11 . Character value: 14 . Character
>> value: 15 . Character value: 16 . Character value: 17 . Character value: 18
>> . Character value: 19 . Character value: 20 . Character value: 21 .
>> Character value: 22 . Character value: 23 . Character value: 24 . Character
>> value: 25 . Character value: 26 . Character escape . Character value: 28 .
>> Character value: 29 . Character value: 30 . Character value: 31 . $! . $% .
>> $& . $* . $+ . $, . $- . $/ . $< . $= . $> . $? . $@ . $\ . $` . $~ .
>> Character delete . $€ . $ . $‚ . $ƒ . $„ . $… . $† . $‡ . $ˆ . $‰ . $Š . $‹
>> . $Œ . $ . $Ž . $ . $ . $‘ . $’ . $“ . $” . $• . $– . $— . $˜ . $™ . $š .
>> $› . $œ . $ . $ž . $Ÿ . $  . $¡ . $¢ . $£ . $¤ . $¥ . $¦ . $§ . $¨ . $© .
>> $« . $¬ . $­ . $® . $¯ . $° . $± . $² . $³ . $´ . $¶ . $· . $¸ . $¹ . $» .
>> $¼ . $½ . $¾ . $¿ . $× . $÷}
>>
>> This means you can define a method with for example the name "÷".
>>
>> So , the question I want to ask. What do we want to allow as a binary
>> selector (character).
>> All that is nowadays "parseable" as binary selector, or only the set of
>> "special characters"
>> or something between both, and where to put this information, the "this
>> is an allowed binary
>> selector character" information?
>>
>> Thanks
>> Nicolai
>>
>>
>
>

Re: [Pharo-dev] IceBerg and push for projects vs packages

[Nicolas Passerini]

Well, I am not sure if this has to do with Iceberg itself, because Iceberg
does nothing with dependencies.

But I am not sure that a ConfigurationOfXXX really has information of only
one package. Normally you will have only one configuration for each
project, am I wrong?
Then the configuration specifies (among other stuff) dependencies between
the parts (packages) of your project... I think this is right.
If you depend in another project, then you should not depend in specific
packages but in another configuration.

The problem here is that we are (at least Iceberg is) assuming a
correlation between project and repository, because in fact Iceberg handles
repositories. If a project would be spawn in several repositories, at least
now Iceberg can't do anything about it, it will treat them as independent
"projects". I am not sure about changing this logic in the near future, and
also we should think if that is not a Cargo/Metacello feature.

On Sat, Aug 27, 2016 at 10:35 AM, Peter Uhnak  wrote:

> Hi,
>
> one thing that I wanted to ask about IceBerg --- during the IceBerg talk
> Nico mentioned that we need to think in terms of projects.
>
> Now I understand that perspective, because that's how git behaves and
> that's how _I_ think,
>
> however at the same time, there is a strong push for focusing on
> packages... having each package describing it's dependencies, etc.
>
> So my question is, how do those two views interact with each other?
> Because I feel like they are going against each other.
>
> Peter
>
>