Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

[Clément Bera]

On Wed, Nov 22, 2017 at 9:05 PM, Stephane Ducasse 
wrote:

> Hi clement
>
> you should discuss with marcus. I had the impression that he was
> thinking that slot should disappear.
>

Then let's use fieldAt:/fieldAt:put:


>
> Stef
>
> On Wed, Nov 22, 2017 at 2:35 PM, Clément Bera 
> wrote:
> > Hi All,
> >
> > It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that
> the
> > instVarAt: / instVarAt:put: primitive is not doing what it says it does.
> > When I look at Object>>#instVarAt: I see:
> >
> > "[...]Answer a fixed variable in an object. The numbering of the
> variables
> > corresponds to the named instance variables, followed by the indexed
> > instance
> > variables. Fail if the index is not an Integer or is not the index of a
> > fixed variable[...]"
> >
> > Now in Pharo 7 when one does:
> >
> > #(iv1) instVarAt: 1, one gets #iv1.
> >
> > So the comment is wrong.
> >
> > The reason for this is that instVarAt: / instVarAt:put: should be
> primitive
> > 73/74, while they are in Pharo 173/174 (primitive slotAt:/slotAt:put:).
> The
> > slot primitive access pointer slots of objects, whichever inst var or
> > variable fields. A good example would be:
> >
> > | t |
> > t := #temp.
> > [ t ] instVarAt: 4, one gets #temp
> >
> > So I have two solutions for this problem:
> > 1) We change the instVarAt: / instVarAt:put: primitives comments to match
> > the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: /
> instVarAt:put:
> > means in factslotAt: / slotAt:put: .
> > 2) We change the instVarAt: / instVarAt:put: primitives to primitive 73
> and
> > 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we ask
> > everyone to fix their code relying on instVarAt: / instVarAt:put: acting
> as
> > slotAt: / slotAt:put:
> >
> > What do you think ?
> >
> > Best,
> >
> >
> > --
> > Clément Béra
> > Pharo consortium engineer
> > https://clementbera.wordpress.com/
> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Bloc Naming Suggestion

[Nicolas Cellier]

I see same kind of names in Opal exceptions
Maybe the intention was to clearly distinguish Error from Warning
(proceedable), but the hierarchy tells already.

OCSemanticError
OCStoreIntoReadOnlyVariableError could be just OCStoreIntoReadOnlyVariable
OCStoreIntoSpecialVariableError -> OCStoreIntoSpecialVariable

OCSemanticWarning
OCShadowVariableWarning
OCUndeclaredVariableWarning

Note that removing the Warning suffix might lead to ambiguous names...
OCUndeclaredVariable might be confused as being a Variable.
So maybe OCVariableUndeclared or OCVariableIsUndeclared

2017-11-22 21:25 GMT+01:00 Stephane Ducasse :

> +1
>
>
> On Sun, Nov 19, 2017 at 4:34 PM, Tudor Girba  wrote:
> > I think it’s not a bad idea.
> >
> > Doru
> >
> >> On Nov 19, 2017, at 4:31 PM, Sean P. DeNigris 
> wrote:
> >>
> >> What do you think about removing the #Attribute suffix from all the
> >> BrTextAttribute subclasses? The names seem pretty long (e.g.
> >> BrFontGenericFamilyAttribute, the longest) and IMHO `BrTextAttribute
> >> subclass: #BrFontWeight` is adequately intention revealing. Thoughts?
> >>
> >>
> >>
> >> -
> >> Cheers,
> >> Sean
> >> --
> >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.
> html
> >>
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "Problem solving efficiency grows with the abstractness level of problem
> understanding."
> >
> >
> >
> >
> >
>
>

Re: [Pharo-dev] [ANN] Willow 4.0.0 released!

[Stephane Ducasse]

Hi stephan

I totally agree. So much things to try and not enough time


On Sun, Nov 19, 2017 at 1:48 PM, Stephan Eggermont  wrote:
> Op 16-11-2017 om 15:44 schreef Gabriel Cotelli:
>>
>> Hi,
>>
>> We're happy to announce the general availability of Willow and it's
>> related projects in the Web Stack ecosystem hosted at
>> https://github.com/ba-st/.
>>
>> Willow is a Web Interaction Library that eases the burden of creating
>> AJAX-based web applications. The project goals are:
>
>
> Interesting approach. Might be useful to use as a target for (QC)Magritte.
> So much things to try out, and not enough time!
>
> Stephan
>
>

Re: [Pharo-dev] Deploying using the latest minimal image of Pharo (6.1)

[Stephane Ducasse]

Hi Gabriel

This is cool.
Thanks for sharing it with us.
I really want an object responsible for deploying an app. :)
Your effort is nice in that directory. Keep pushing

Stef


On Sun, Nov 19, 2017 at 1:33 AM, gabriel sor
 wrote:
> Hi,
> In in the past days, in the context of the Smalltalks 2017 conference, I
> talked about my attempt to deploy on  production using the minimal image
> of Pharo .
>  My goal was prepare an inmutable or staless minimal image for deploy,
> without sources nor changes files.
>  The results are exposed in this  tutorial.
> The size of the image is 16 MB and it has loaded Seaside.
>   Just I have a pendeing issue: the staless image but everything else is
> done and working.
>

Re: [Pharo-dev] Bloc Naming Suggestion

[Stephane Ducasse]

+1


On Sun, Nov 19, 2017 at 4:34 PM, Tudor Girba  wrote:
> I think it’s not a bad idea.
>
> Doru
>
>> On Nov 19, 2017, at 4:31 PM, Sean P. DeNigris  wrote:
>>
>> What do you think about removing the #Attribute suffix from all the
>> BrTextAttribute subclasses? The names seem pretty long (e.g.
>> BrFontGenericFamilyAttribute, the longest) and IMHO `BrTextAttribute
>> subclass: #BrFontWeight` is adequately intention revealing. Thoughts?
>>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Problem solving efficiency grows with the abstractness level of problem 
> understanding."
>
>
>
>
>

Re: [Pharo-dev] nil suspend

[Stephane Ducasse]

+1


On Mon, Nov 20, 2017 at 10:06 AM, Guillermo Polito <
guillermopol...@gmail.com> wrote:

> Yes, it doesn't sound right. I vote for removal :)
>
> On Sat, Nov 18, 2017 at 11:04 PM, Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com> wrote:
>
>> It sounds like a left over...
>> no time stamp in Squeak, so it must be old.
>> Display reverse; reverse means we wanted to catch when such oddity was
>> necessary.
>> (I would do it differently with an Exception and a MessageTally like I
>> already exhibited several times)
>> The fact that reverse; reverse was commented is more difficult to
>> interpret... Is it really necessary?
>> I removed the method in a Squeak image, and so fare nothing wrong
>> happened, but it does not prove anything.
>> The best is to ask in Squeak lists, maybe someone can remember...
>> Or carefully analyze all senders of suspend...
>>
>> 2017-11-18 22:36 GMT+01:00 Aliaksei Syrel :
>>
>>> Hi,
>>>
>>> I was looking at nil (already funny) and found a very interesting
>>> method:
>>>
>>> suspend
>>>"Kills off processes that didn't terminate properly"
>>>"Display reverse; reverse."  "<-- So we can catch the suspend bug"
>>>Processor terminateActive
>>>
>>> It means that the following code is probably the shortest way to kill
>>> your image (save first!)
>>>
>>> nil suspend
>>>
>>> It terminates a UI process if evaluated from anywhere using CMD+d :D
>>>
>>> Cheers,
>>> Alex
>>>
>>
>>
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>

Re: [Pharo-dev] Advent of code

[Stephane Ducasse]

Ok can you put a link on the advent of code web page?

On Wed, Nov 22, 2017 at 9:11 PM, Julien  wrote:

> I’ll write a README with some instructions to avoid clash when merging
> pull requests.
>
> For example, each participant could create a directory with its name and
> put all his stuff inside it.
>
> Julien
>
> Le 22 nov. 2017 à 21:09, Stephane Ducasse  a
> écrit :
>
> Tx I forked it.
>
> On Wed, Nov 22, 2017 at 5:38 PM, Julien 
> wrote:
>
>> Ok I created one [1], maybe if multiple people are playing with me we can
>> gather the different solutions we get for each puzzle in this repository.
>>
>> Julien
>>
>> [1]: https://github.com/juliendelplanque/AdventOfCode2017WithPharo
>>
>> Le 22 nov. 2017 à 16:55, Stephane Ducasse  a
>> écrit :
>>
>> Julien
>>
>> could you open a github project so that we can do the same as norviq?
>> And get a log of the problems and solution?
>>
>> Stef
>>
>> On Wed, Nov 22, 2017 at 2:25 PM, Serge Stinckwich <
>> serge.stinckw...@gmail.com> wrote:
>>
>>> BTW, the Japanese Smalltalk community is doing an advent Calendar every
>>> year:
>>>
>>> https://qiita.com/advent-calendar/2016/smalltalk
>>>
>>> The 2017 edition is in preparation here: https://qiita.com/advent-calen
>>> dar/2017/smalltalk
>>>
>>>
>>>
>>> On Wed, Nov 22, 2017 at 1:29 PM, Stephane Ducasse <
>>> stepharo.s...@gmail.com> wrote:
>>>
 Hi pharoers

 I would like to know if you would like to participate to
 http://adventofcode.com/2016

 For example we could do the same as
 https://github.com/norvig/pytudes/blob/master/ipynb/Advent%2
 0of%20Code.ipynb

 Stef


>>>
>>>
>>> --
>>> Serge Stinckwich
>>> UMI UMMISCO 209 (IRD/UPMC/UY1)
>>> "Programs must be written for people to read, and only incidentally for
>>> machines to execute."http://www.doesnotunderstand.org/
>>>
>>
>>
>>
>
>

Re: [Pharo-dev] balloonHelp for menus

[Stephane Ducasse]

We were brainstorming about how to "radically" change iceberg to
convey the complexity of the situation and
I was suggesting to have long menu to educate us (poor people).

I proposed for icecube (the tool for newbies that do not want to work
on fork and just want to get the MC workflow) the following:

- “clone a repo" (with the indication if this is https or ssh)
- “fetch (remote -> local)"
- “commit (image -> local)”
- “push (local -> remote)"
- “load (local -> image)”
- “merge (local -> image)"
- "pull  (fetch + load)"

Fetch and Pull should not have the same icons

Optional
- “create branch”
- “switch branch”

And yes I want long menu to tell me all the time key information about
the action.
Stef


On Mon, Nov 20, 2017 at 10:44 PM, Nicolas Cellier
 wrote:
> Hi again,
> I see no balloon help in menus in Pharo 7.0.
> Some menu labels are intention revealing and a balloon paraphrasing the
> label is useless.
> But that's not the general case, some complex actions like found in Iceberg
> interface would deserve a bit more explanations for noobs like me.
> A link from the menu to some Help topic would also be more than welcome
> (maybe thru an anchor, a tag or some other machinery...)

Re: [Pharo-dev] method usage example: annotation or comment?

[Stephane Ducasse]

Hi nicolas

I do not know what are < expr: (foo) results: bar > may be this is
even me that tried something (shame on me)
but I think that we should clean them.

Now I use "foo >>> bar" because we can have non literal and we will
start to build tools based on them.

I would like to clean the proliferation of pragmas too.

Stef




On Mon, Nov 20, 2017 at 9:33 PM, Nicolas Cellier
 wrote:
> Hi,
> I encountered some annotations in the form:
>
> < expr: (foo) result: bar >
>
> and some meta comments of the form:
>
> " foo >>> bar "
>
> I think both are aimed at providing examples of method usage for
> documentation, non regression testing, etc...
>
> I note that the former is requiring a literal result, which is quite
> limiting (1/3) is not a literal for example, 0@0 neither...
> IMO it should be extended for handling any valid expression.
> But that still makes two different ways of expressing the same intent. So
> what's the canonical one?

Re: [Pharo-dev] OpalCompiler evaluate speed

[Stephane Ducasse]

Thanks this is good.
I think that Opal deserves more energy.
We are busy right now. Now marcus will certainly be interested.
It will also speed up part of the bootstrap.

Stef

On Tue, Nov 21, 2017 at 2:19 PM, Nicolas Cellier
 wrote:
> I have an ArbitraryPrecisionFloatTests doing an exhaustive test for printing
> and reevaluating all positve half precision float.
>
> That's about 2^15 or approximately 32k loop which evaluate snippets like
>
> (ArbitraryPrecisionFloat readFrom: '1.123' readStream numBits: 10)
>
> The test was naively written with Compiler evaluate: and was using the
> legacy Compiler.
>
> If I rewrite self class compiler evaluate: the test times out.
> Let's see what increase is necessary:
>
> [ ArbitraryPrecisionFloatTest new testPrintAndEvaluate  ] timeToRun.
> -> 3s with legacy Compiler
> -> 14s with OpalCompiler
>
> It's not unexpected that intermediate representation (IR) reification has a
> cost, but here the 4.5x is a bit too much...
> This test did account for 1/4 of total test duration already (3s out of
> 12s).
> With Opal, the total test duration doubles... (14s out of 23s)
>
> So let's analyze the hot spot with:
>
> MessageTally  spyOn: [ ArbitraryPrecisionFloatTest new
> testPrintAndEvaluate  ].
>
> (I didn't use AndreasSystemProfiler becuase outputs seems a bit garbbled, no
> matter since the primitives do not account that much, a MessageTally will do
> the job)
>
> I first see a hot spot which does not seem that necessary:
>
>   ||24.6% {3447ms} RBMethodNode(RBProgramNode)>>formattedCode
>
> From the comments I understand that AST-based stuff requires a pattern
> (DoIt) and an explicit return (^), but this expensive formatting seems too
> much for just evaluating. i think that we should change that.
>
> Then comes:
>
>   ||20.7% {2902ms} RBMethodNode>>generate:
>
> which is split in two halves, ATS->IR and IR->bytecode
>
>   ||  |9.3% {1299ms} RBMethodNode>>generateIR
>
>   ||  |  |11.4% {1596ms} IRMethod>>generate:
>
> But then I see this cost a 2nd time which also leave room for progress:
>
>   ||10.9% {1529ms} RBMethodNode>>generateIR
>
>   ||  |12.9% {1814ms} IRMethod>>generate:
>
> The first is in RBMethodNode>>generateWithSource, the second in
> OpalCompiler>>compile
>
> Last comes the parse time (sourceCode -> AST)
>
>   |  13.2% {1858ms} OpalCompiler>>parse
>
> Along with semantic analysis
>
>   |  6.0% {837ms} OpalCompiler>>doSemanticAnalysis
>
> ---
>
> For comparison, the legacy Compiler decomposes into:
>
>   ||61.5% {2223ms}
> Parser>>parse:class:category:noPattern:context:notifying:ifFail:
>
> which more or less covers parse time + semantic analysis time.
> That means that Opal does a fair work for this stage.
>
> Then, the direct AST->byteCode phase is:
>
>  |  16.9% {609ms} MethodNode>>generate
>
> IR costs almost a 5x on this phase, but we know it's the price to pay for
> the additional features that it potentially offers. If only we would do it
> once...
>
> And that's all for the legacy one...
>
> --
>
> This little exercize shows that a 2x acceleration of OpalCompiler evaluate
> seems achievable:
> - simplify the uselessely expensive formatted code
> - generate bytecodes once, not twice
>
> Then it will be a bit more 2x slower than legacy, which is a better trade
> for yet to come superior features potentially brought by Opal.
>
> It would be interesting to carry same analysis on method compilation

Re: [Pharo-dev] Advent of code

[Julien]

I’ll write a README with some instructions to avoid clash when merging pull 
requests.

For example, each participant could create a directory with its name and put 
all his stuff inside it.

Julien

> Le 22 nov. 2017 à 21:09, Stephane Ducasse  a écrit :
> 
> Tx I forked it. 
> 
> On Wed, Nov 22, 2017 at 5:38 PM, Julien  > wrote:
> Ok I created one [1], maybe if multiple people are playing with me we can 
> gather the different solutions we get for each puzzle in this repository.
> 
> Julien
> 
> [1]: https://github.com/juliendelplanque/AdventOfCode2017WithPharo 
> 
> 
>> Le 22 nov. 2017 à 16:55, Stephane Ducasse > > a écrit :
>> 
>> Julien 
>> 
>> could you open a github project so that we can do the same as norviq?
>> And get a log of the problems and solution?
>> 
>> Stef
>> 
>> On Wed, Nov 22, 2017 at 2:25 PM, Serge Stinckwich 
>> > wrote:
>> BTW, the Japanese Smalltalk community is doing an advent Calendar every year:
>> 
>> https://qiita.com/advent-calendar/2016/smalltalk 
>> 
>> 
>> The 2017 edition is in preparation here: 
>> https://qiita.com/advent-calendar/2017/smalltalk 
>> 
>> 
>> 
>> 
>> On Wed, Nov 22, 2017 at 1:29 PM, Stephane Ducasse > > wrote:
>> Hi pharoers
>> 
>> I would like to know if you would like to participate to
>> http://adventofcode.com/2016 
>> 
>> For example we could do the same as
>> https://github.com/norvig/pytudes/blob/master/ipynb/Advent%20of%20Code.ipynb 
>> 
>> 
>> Stef
>> 
>> 
>> 
>> 
>> -- 
>> Serge Stinckwich
>> UMI UMMISCO 209 (IRD/UPMC/UY1)
>> "Programs must be written for people to read, and only incidentally for 
>> machines to execute."
>> http://www.doesnotunderstand.org/ 
> 
> 

Re: [Pharo-dev] Advent of code

[Stephane Ducasse]

Tx I forked it.

On Wed, Nov 22, 2017 at 5:38 PM, Julien  wrote:

> Ok I created one [1], maybe if multiple people are playing with me we can
> gather the different solutions we get for each puzzle in this repository.
>
> Julien
>
> [1]: https://github.com/juliendelplanque/AdventOfCode2017WithPharo
>
> Le 22 nov. 2017 à 16:55, Stephane Ducasse  a
> écrit :
>
> Julien
>
> could you open a github project so that we can do the same as norviq?
> And get a log of the problems and solution?
>
> Stef
>
> On Wed, Nov 22, 2017 at 2:25 PM, Serge Stinckwich <
> serge.stinckw...@gmail.com> wrote:
>
>> BTW, the Japanese Smalltalk community is doing an advent Calendar every
>> year:
>>
>> https://qiita.com/advent-calendar/2016/smalltalk
>>
>> The 2017 edition is in preparation here: https://qiita.com/advent-calen
>> dar/2017/smalltalk
>>
>>
>>
>> On Wed, Nov 22, 2017 at 1:29 PM, Stephane Ducasse <
>> stepharo.s...@gmail.com> wrote:
>>
>>> Hi pharoers
>>>
>>> I would like to know if you would like to participate to
>>> http://adventofcode.com/2016
>>>
>>> For example we could do the same as
>>> https://github.com/norvig/pytudes/blob/master/ipynb/Advent%2
>>> 0of%20Code.ipynb
>>>
>>> Stef
>>>
>>>
>>
>>
>> --
>> Serge Stinckwich
>> UMI UMMISCO 209 (IRD/UPMC/UY1)
>> "Programs must be written for people to read, and only incidentally for
>> machines to execute."http://www.doesnotunderstand.org/
>>
>
>
>

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo TechTalk 21 Nov: Discord Demo

[Stephane Ducasse]

Thanks Juraj!
I want to watch it.

On Wed, Nov 22, 2017 at 7:45 PM, Sean P. DeNigris  wrote:
> Juraj Kubelka wrote
>> I will upload recording I have on my computer. It is clear.
>
> Thanks!
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

[Stephane Ducasse]

Hi clement

you should discuss with marcus. I had the impression that he was
thinking that slot should disappear.

Stef

On Wed, Nov 22, 2017 at 2:35 PM, Clément Bera  wrote:
> Hi All,
>
> It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that the
> instVarAt: / instVarAt:put: primitive is not doing what it says it does.
> When I look at Object>>#instVarAt: I see:
>
> "[...]Answer a fixed variable in an object. The numbering of the variables
> corresponds to the named instance variables, followed by the indexed
> instance
> variables. Fail if the index is not an Integer or is not the index of a
> fixed variable[...]"
>
> Now in Pharo 7 when one does:
>
> #(iv1) instVarAt: 1, one gets #iv1.
>
> So the comment is wrong.
>
> The reason for this is that instVarAt: / instVarAt:put: should be primitive
> 73/74, while they are in Pharo 173/174 (primitive slotAt:/slotAt:put:). The
> slot primitive access pointer slots of objects, whichever inst var or
> variable fields. A good example would be:
>
> | t |
> t := #temp.
> [ t ] instVarAt: 4, one gets #temp
>
> So I have two solutions for this problem:
> 1) We change the instVarAt: / instVarAt:put: primitives comments to match
> the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: / instVarAt:put:
> means in factslotAt: / slotAt:put: .
> 2) We change the instVarAt: / instVarAt:put: primitives to primitive 73 and
> 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we ask
> everyone to fix their code relying on instVarAt: / instVarAt:put: acting as
> slotAt: / slotAt:put:
>
> What do you think ?
>
> Best,
>
>
> --
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

[Pharo-dev] [Pharo 7.0-dev] Build #318: 20739-Remove-dead-stream-primitives

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #318 was: SUCCESS.

The Pull Request #524 was integrated: "20739-Remove-dead-stream-primitives"
Pull request url: https://github.com/pharo-project/pharo/pull/524

Issue Url: https://pharo.fogbugz.com/f/cases/20739
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/318/

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo TechTalk 21 Nov: Discord Demo

[Sean P. DeNigris]

Juraj Kubelka wrote
> I will upload recording I have on my computer. It is clear.

Thanks!



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Advent of code

[Julien]

Ok I created one [1], maybe if multiple people are playing with me we can 
gather the different solutions we get for each puzzle in this repository.

Julien

[1]: https://github.com/juliendelplanque/AdventOfCode2017WithPharo

> Le 22 nov. 2017 à 16:55, Stephane Ducasse  a écrit :
> 
> Julien 
> 
> could you open a github project so that we can do the same as norviq?
> And get a log of the problems and solution?
> 
> Stef
> 
> On Wed, Nov 22, 2017 at 2:25 PM, Serge Stinckwich  > wrote:
> BTW, the Japanese Smalltalk community is doing an advent Calendar every year:
> 
> https://qiita.com/advent-calendar/2016/smalltalk 
> 
> 
> The 2017 edition is in preparation here: 
> https://qiita.com/advent-calendar/2017/smalltalk 
> 
> 
> 
> 
> On Wed, Nov 22, 2017 at 1:29 PM, Stephane Ducasse  > wrote:
> Hi pharoers
> 
> I would like to know if you would like to participate to
> http://adventofcode.com/2016 
> 
> For example we could do the same as
> https://github.com/norvig/pytudes/blob/master/ipynb/Advent%20of%20Code.ipynb 
> 
> 
> Stef
> 
> 
> 
> 
> -- 
> Serge Stinckwich
> UMI UMMISCO 209 (IRD/UPMC/UY1)
> "Programs must be written for people to read, and only incidentally for 
> machines to execute."
> http://www.doesnotunderstand.org/ 

Re: [Pharo-dev] Advent of code

[Serge Stinckwich]

On Wed, Nov 22, 2017 at 4:55 PM, Stephane Ducasse 
wrote:

> Julien
>
> could you open a github project so that we can do the same as norviq?
> And get a log of the problems and solution?
>
>
​Yes would be nice.

-- 
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC/UY1)
"Programs must be written for people to read, and only incidentally for
machines to execute."http://www.doesnotunderstand.org/

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo TechTalk 21 Nov: Discord Demo

[Juraj Kubelka]

> On Nov 21, 2017, at 19:54, Dimitris Chloupis  wrote:
> 
> Well done :)
> 
> Now you can make a discord client inside the Pharo image if you want. 

Exactly :-) I am looking for integrations that improve the developer 
experience. Maybe the interface should be different from the standard client. 
The question is how to integrate and why? What do you think?

Cheers,
Juraj

> On Tue, 21 Nov 2017 at 21:03, Juraj Kubelka  > wrote:
> Hi,
> 
> the TechTalk record is available at the same link: 
> https://www.youtube.com/watch?v=33kXsOiP6wA 
>  
> and includes outline to simplify navigation.
> 
> Cheers,
> Juraj
> 
> 
> TechTalk Outline:
> - 01:58 The beginning of the talk
> - 04:30 Webhook
>   - 04:33 How to Create Webhook
>   - 05:39 Webhook Examples
>   - 10:33 Webhook Use Case: Script of the Day from Nautilus Code Browser
>   - 18:39 Webhook Use Case: Server Problem Notification
> - 22:45 Bot App (chatbot)
>   - 24:47 How to Create a Bot App
>   - 28:28 Bot App Examples
>   - 33:17 Bot Use Case: Source Code Expertise
> - 41:40 Standard User Client
>   - 42:57 User Client Example
>   - 45:06 User Client Use Case: Asking Directly from Pharo Playground
>   - 47:06 User Client Use Case: Receiving Questions and Answering in Pharo
>   - 50:50 Final Thoughts About Discord Integration in Inspector and Debugger
> - 52:44 Discussion
> 
>> On Nov 21, 2017, at 12:54, Juraj Kubelka > > wrote:
>> 
>> Hi!
>> 
>> The TechTalk starts in about 10 minutes. Join us on Discord, the techtalk 
>> channel.
>> 
>> Cheers,
>> Juraj
>> 
>> 
>>> On Nov 21, 2017, at 10:11, Marcus Denker >> > wrote:
>>> 
>>> The link to the live stream is this:
>>> 
>>>  https://www.youtube.com/watch?v=33kXsOiP6wA 
>>> 
>>> 
>>> It start in a bit less than 3 hours.
>>> 
>>> Marcus
>>> 
 On 18 Nov 2017, at 09:13, Marcus Denker > wrote:
 
 Pharo TechTalk: Discord Demo
 When?  21 Nov 2017 5:00 PM - 7:00 PM (UTC+01:00)
 
 Topic: "Discord communication Demo”, how to script discord from Pharo.
 
https://association.pharo.org/event-2642665 
 
>>> 
>> 
> 

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo TechTalk 21 Nov: Discord Demo

[Juraj Kubelka]

> On Nov 21, 2017, at 21:57, Sean P. DeNigris  wrote:
> 
> Juraj Kubelka wrote
>> the TechTalk record is available at the same link:
>> https://www.youtube.com/watch?v=33kXsOiP6wA 
> 
> Thanks! The quality seems to top out at 480p, which is pretty blurry. It
> makes the code nearly unreadable. Any way to bump the resolution on the next
> one?

I do not know how to improve the streaming itself. Maybe the internet speed was 
not perfect that day in Chile.
I will upload recording I have on my computer. It is clear.

Cheers,
Juraj

> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

Re: [Pharo-dev] Advent of code

[Stephane Ducasse]

Julien

could you open a github project so that we can do the same as norviq?
And get a log of the problems and solution?

Stef

On Wed, Nov 22, 2017 at 2:25 PM, Serge Stinckwich <
serge.stinckw...@gmail.com> wrote:

> BTW, the Japanese Smalltalk community is doing an advent Calendar every
> year:
>
> https://qiita.com/advent-calendar/2016/smalltalk
>
> The 2017 edition is in preparation here: https://qiita.com/advent-
> calendar/2017/smalltalk
>
>
>
> On Wed, Nov 22, 2017 at 1:29 PM, Stephane Ducasse  > wrote:
>
>> Hi pharoers
>>
>> I would like to know if you would like to participate to
>> http://adventofcode.com/2016
>>
>> For example we could do the same as
>> https://github.com/norvig/pytudes/blob/master/ipynb/Advent%
>> 20of%20Code.ipynb
>>
>> Stef
>>
>>
>
>
> --
> Serge Stinckwich
> UMI UMMISCO 209 (IRD/UPMC/UY1)
> "Programs must be written for people to read, and only incidentally for
> machines to execute."http://www.doesnotunderstand.org/
>

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

[Clément Bera]

On Wed, Nov 22, 2017 at 3:34 PM, Denis Kudriashov 
wrote:

> Hi.
>
> Just to notice: it is here long time (I checked Pharo 1 and current
> Squeak).
>
> Probably some Spur changes to integrate in the image then.


>
> 2017-11-22 14:35 GMT+01:00 Clément Bera :
>
>> Hi All,
>>
>> It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that
>> the instVarAt: / instVarAt:put: primitive is not doing what it says it
>> does. When I look at Object>>#instVarAt: I see:
>>
>> "[...]Answer a fixed variable in an object. The numbering of the variables
>> corresponds to the named instance variables, followed by the indexed
>> instance
>> variables. Fail if the index is not an Integer or is not the index of a
>> fixed variable[...]"
>>
>> Now in Pharo 7 when one does:
>>
>> #(iv1) instVarAt: 1, one gets #iv1.
>>
>> So the comment is wrong.
>>
>> The reason for this is that instVarAt: / instVarAt:put: should be
>> primitive 73/74, while they are in Pharo 173/174 (primitive
>> slotAt:/slotAt:put:). The slot primitive access pointer slots of objects,
>> whichever inst var or variable fields. A good example would be:
>>
>> | t |
>> t := #temp.
>> [ t ] instVarAt: 4, one gets #temp
>>
>> So I have two solutions for this problem:
>> 1) We change the instVarAt: / instVarAt:put: primitives comments to match
>> the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: /
>> instVarAt:put: means in factslotAt: / slotAt:put: .
>> 2) We change the instVarAt: / instVarAt:put: primitives to primitive 73
>> and 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we
>> ask everyone to fix their code relying on instVarAt: / instVarAt:put:
>> acting as slotAt: / slotAt:put:
>>
>
> I prefer explicit behaviour. These methods have clear intention in names:
> inst var accessing. It should be error when given index is out of #instSize
> range.
>
> For new methods I would not use slot based naming because slots in Pharo
> is already something more then just object fields.
> Maybe #fieldAt:, #fieldAt:put: would be good? And also #fieldSize for
> consistency
>

fieldSize is not a primitive in this case,

Object>>#fieldSize
 ^ self class instSize + self basicSize


>
>>
>> What do you think ?
>>
>> Best,
>>
>>
>> --
>> Clément Béra
>> Pharo consortium engineer
>> https://clementbera.wordpress.com/
>> Bâtiment B 40, avenue Halley 59650
>> Villeneuve
>> d
>> 
>> 'Ascq
>> 
>>
>
>


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

[Denis Kudriashov]

Hi.

Just to notice: it is here long time (I checked Pharo 1 and current Squeak).


2017-11-22 14:35 GMT+01:00 Clément Bera :

> Hi All,
>
> It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that the
> instVarAt: / instVarAt:put: primitive is not doing what it says it does.
> When I look at Object>>#instVarAt: I see:
>
> "[...]Answer a fixed variable in an object. The numbering of the variables
> corresponds to the named instance variables, followed by the indexed
> instance
> variables. Fail if the index is not an Integer or is not the index of a
> fixed variable[...]"
>
> Now in Pharo 7 when one does:
>
> #(iv1) instVarAt: 1, one gets #iv1.
>
> So the comment is wrong.
>
> The reason for this is that instVarAt: / instVarAt:put: should be
> primitive 73/74, while they are in Pharo 173/174 (primitive
> slotAt:/slotAt:put:). The slot primitive access pointer slots of objects,
> whichever inst var or variable fields. A good example would be:
>
> | t |
> t := #temp.
> [ t ] instVarAt: 4, one gets #temp
>
> So I have two solutions for this problem:
> 1) We change the instVarAt: / instVarAt:put: primitives comments to match
> the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: /
> instVarAt:put: means in factslotAt: / slotAt:put: .
> 2) We change the instVarAt: / instVarAt:put: primitives to primitive 73
> and 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we
> ask everyone to fix their code relying on instVarAt: / instVarAt:put:
> acting as slotAt: / slotAt:put:
>

I prefer explicit behaviour. These methods have clear intention in names:
inst var accessing. It should be error when given index is out of #instSize
range.

For new methods I would not use slot based naming because slots in Pharo is
already something more then just object fields.
Maybe #fieldAt:, #fieldAt:put: would be good? And also #fieldSize for
consistency


>
> What do you think ?
>
> Best,
>
>
> --
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650
> Villeneuve
> d
> 
> 'Ascq
> 
>

[Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

[Clément Bera]

Hi All,

It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that the
instVarAt: / instVarAt:put: primitive is not doing what it says it does.
When I look at Object>>#instVarAt: I see:

"[...]Answer a fixed variable in an object. The numbering of the variables
corresponds to the named instance variables, followed by the indexed
instance
variables. Fail if the index is not an Integer or is not the index of a
fixed variable[...]"

Now in Pharo 7 when one does:

#(iv1) instVarAt: 1, one gets #iv1.

So the comment is wrong.

The reason for this is that instVarAt: / instVarAt:put: should be primitive
73/74, while they are in Pharo 173/174 (primitive slotAt:/slotAt:put:). The
slot primitive access pointer slots of objects, whichever inst var or
variable fields. A good example would be:

| t |
t := #temp.
[ t ] instVarAt: 4, one gets #temp

So I have two solutions for this problem:
1) We change the instVarAt: / instVarAt:put: primitives comments to match
the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: /
instVarAt:put: means in factslotAt: / slotAt:put: .
2) We change the instVarAt: / instVarAt:put: primitives to primitive 73 and
74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we ask
everyone to fix their code relying on instVarAt: / instVarAt:put: acting as
slotAt: / slotAt:put:

What do you think ?

Best,


-- 
Clément Béra
Pharo consortium engineer
https://clementbera.wordpress.com/
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Re: [Pharo-dev] Advent of code

[Serge Stinckwich]

BTW, the Japanese Smalltalk community is doing an advent Calendar every
year:

https://qiita.com/advent-calendar/2016/smalltalk

The 2017 edition is in preparation here:
https://qiita.com/advent-calendar/2017/smalltalk



On Wed, Nov 22, 2017 at 1:29 PM, Stephane Ducasse 
wrote:

> Hi pharoers
>
> I would like to know if you would like to participate to
> http://adventofcode.com/2016
>
> For example we could do the same as
> https://github.com/norvig/pytudes/blob/master/ipynb/
> Advent%20of%20Code.ipynb
>
> Stef
>
>


-- 
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC/UY1)
"Programs must be written for people to read, and only incidentally for
machines to execute."http://www.doesnotunderstand.org/

Re: [Pharo-dev] Advent of code

[Julien]

The 2017 version will be online on 1st December normally.

I will participate for sure, I implemented some of the algorithms of 2016 
versions and I’d say that Pharo is really cool to do that because of its nice 
Collections framework (a lot of exercises are about extracting data 
from/transforming/interpret data-structures provided serialised in a text file).

:-)

Julien

> Le 22 nov. 2017 à 13:29, Stephane Ducasse  a écrit :
> 
> Hi pharoers
> 
> I would like to know if you would like to participate to
> http://adventofcode.com/2016
> 
> For example we could do the same as
> https://github.com/norvig/pytudes/blob/master/ipynb/Advent%20of%20Code.ipynb
> 
> Stef
> 

[Pharo-dev] [Pharo 7.0-dev] Build #317: 20645-Windows-rebuildFieldAccessors-problem

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #317 was: SUCCESS.

The Pull Request #521 was integrated: 
"20645-Windows-rebuildFieldAccessors-problem"
Pull request url: https://github.com/pharo-project/pharo/pull/521

Issue Url: https://pharo.fogbugz.com/f/cases/20645
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/317/

[Pharo-dev] Advent of code

[Stephane Ducasse]

Hi pharoers

I would like to know if you would like to participate to
http://adventofcode.com/2016

For example we could do the same as
https://github.com/norvig/pytudes/blob/master/ipynb/Advent%20of%20Code.ipynb

Stef

Re: [Pharo-dev] Pharo 6.1 64 bits segmentation fault loading code on Linux

[Thierry Goubier]

2017-11-22 13:03 GMT+01:00 Gabriel Cotelli :

> Well that make sense. The problem is that the stable VM is crashing with a
> segmentation fault :( on Linux/64 bits.
>

I can confirm.

Given that later vms do not segfault, Eliot told me he prefers to consider
the bug(*) solved.

Thierry

(*) But I have no idea about what the bug is. Running the stable pharo vm
under valgrind also triggers the segfault, valgrind complains a lot and
signal permamently lost memory, but this is the same with all vms as far as
valgrind is concerned (i.e. non-crashing and even non-pharo vms are no
better, except that they don't crash).


>
> On Nov 22, 2017 08:46, "Esteban Lorenzano"  wrote:
>
>>
>>
>> On 21 Nov 2017, at 21:00, Gabriel Cotelli  wrote:
>>
>> I can't find a latest 6.1 vm so I tried with the Pharo 7 Latest VM (wget
>> -O- get.pharo.org/64/vmTLatest70 | bash) and the 6.1 image but crashes
>> with a segmentation fault also.
>>
>>
>> by concept, there is no “latest 6.1 vm” since latest is “unstable”
>> (alpha) and 6.1 is not (or it shouldn’t).
>>
>> latest is always related to the development version.
>>
>> Esteban
>>
>>
>> On Tue, Nov 21, 2017 at 12:03 PM, Thierry Goubier <
>> thierry.goub...@gmail.com> wrote:
>>
>>> Hi Gabriel,
>>>
>>> I had such segfaults with the stable 6.1/64bits on Linux. I solved them
>>> by ensuring the use of a more recent version than the stable one.
>>>
>>> Thierry
>>>
>>>
>>> 2017-11-21 15:56 GMT+01:00 Gabriel Cotelli :
>>>
 I've created the following issue:

 https://pharo.fogbugz.com/f/cases/20737/Segmentation-fault-t
 rying-to-load-code-into-a-64-bits-Pharo-6-1-Linux
 I can reproduce it easily so if you need some more info let me know.

 Regards,
 Gabriel

>>>
>>>
>>
>>

Re: [Pharo-dev] Pharo 6.1 64 bits segmentation fault loading code on Linux

[Gabriel Cotelli]

Well that make sense. The problem is that the stable VM is crashing with a
segmentation fault :( on Linux/64 bits.

On Nov 22, 2017 08:46, "Esteban Lorenzano"  wrote:

>
>
> On 21 Nov 2017, at 21:00, Gabriel Cotelli  wrote:
>
> I can't find a latest 6.1 vm so I tried with the Pharo 7 Latest VM (wget
> -O- get.pharo.org/64/vmTLatest70 | bash) and the 6.1 image but crashes
> with a segmentation fault also.
>
>
> by concept, there is no “latest 6.1 vm” since latest is “unstable” (alpha)
> and 6.1 is not (or it shouldn’t).
>
> latest is always related to the development version.
>
> Esteban
>
>
> On Tue, Nov 21, 2017 at 12:03 PM, Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
>> Hi Gabriel,
>>
>> I had such segfaults with the stable 6.1/64bits on Linux. I solved them
>> by ensuring the use of a more recent version than the stable one.
>>
>> Thierry
>>
>>
>> 2017-11-21 15:56 GMT+01:00 Gabriel Cotelli :
>>
>>> I've created the following issue:
>>>
>>> https://pharo.fogbugz.com/f/cases/20737/Segmentation-fault-t
>>> rying-to-load-code-into-a-64-bits-Pharo-6-1-Linux
>>> I can reproduce it easily so if you need some more info let me know.
>>>
>>> Regards,
>>> Gabriel
>>>
>>
>>
>
>

Re: [Pharo-dev] Pharo 6.1 64 bits segmentation fault loading code on Linux

[Esteban Lorenzano]

> On 21 Nov 2017, at 21:00, Gabriel Cotelli  wrote:
> 
> I can't find a latest 6.1 vm so I tried with the Pharo 7 Latest VM (wget -O- 
> get.pharo.org/64/vmTLatest70  | bash) 
> and the 6.1 image but crashes with a segmentation fault also.

by concept, there is no “latest 6.1 vm” since latest is “unstable” (alpha) and 
6.1 is not (or it shouldn’t).

latest is always related to the development version.

Esteban

> 
> On Tue, Nov 21, 2017 at 12:03 PM, Thierry Goubier  > wrote:
> Hi Gabriel,
> 
> I had such segfaults with the stable 6.1/64bits on Linux. I solved them by 
> ensuring the use of a more recent version than the stable one.
> 
> Thierry
> 
> 
> 2017-11-21 15:56 GMT+01:00 Gabriel Cotelli  >:
> I've created the following issue:
> 
> https://pharo.fogbugz.com/f/cases/20737/Segmentation-fault-trying-to-load-code-into-a-64-bits-Pharo-6-1-Linux
>  
> 
> I can reproduce it easily so if you need some more info let me know.
> 
> Regards,
> Gabriel
> 
> 

Re: [Pharo-dev] DateAndTime local time zone not initialised in Pharo 7

[Alistair Grant]

Hi Sven,

On 22 November 2017 at 11:08, Sven Van Caekenberghe  wrote:
> In my Pharo 7 images, DateAndTime's local time zone is not initialised.
>
> Normally, Locale class>>#startUp: calls
>
>   DateAndTime localTimeZone: LocalTimeZone new
>
> but that was somehow not the case, hence the image operated as in TZ 0, UTC, 
> offset 0.
>
> Does anyone else see this ?

Yes (just noticed after our other discussion about Dates).

> It seems Locale is not in the #startupList but it should be.
>
> Sven

+1

Cheers,
Alistair

[Pharo-dev] DateAndTime local time zone not initialised in Pharo 7

[Sven Van Caekenberghe]

In my Pharo 7 images, DateAndTime's local time zone is not initialised.

Normally, Locale class>>#startUp: calls 

  DateAndTime localTimeZone: LocalTimeZone new

but that was somehow not the case, hence the image operated as in TZ 0, UTC, 
offset 0.

Does anyone else see this ?

It seems Locale is not in the #startupList but it should be.

Sven

Re: [Pharo-dev] Pharo and special unary selectors

[Peter Uhnák]

I just randomly ran into this project https://github.com/ba-st/aconcagua
which seems to be designed around such unary selectors.

On Sat, Nov 18, 2017 at 12:55 AM, Benoit St-Jean via Pharo-dev <
pharo-dev@lists.pharo.org> wrote:

>
>
> -- Forwarded message --
> From: Benoit St-Jean 
> To: Pharo Development List 
> Cc:
> Bcc:
> Date: Fri, 17 Nov 2017 23:55:56 + (UTC)
> Subject: Re: [Pharo-dev] Pharo and special unary selectors
> Personnally, I against adding those special symbols.  They add close to
> nothing (except complexity in the parser) to what we can actually do!
>
> Besides, what does 30$ + 17$ add up to?  Oh!  Did I tell you it was
> actually $30USD + $17CAN ? :)
>
>
> -
> Benoît St-Jean
> Yahoo! Messenger: bstjean
> Twitter: @BenLeChialeux
> Pinterest: benoitstjean
> Instagram: Chef_Benito
> IRC: lamneth
> Blogue: endormitoire.wordpress.com
> "A standpoint is an intellectual horizon of radius zero".  (A. Einstein)
>
>
> On Friday, November 17, 2017, 6:41:11 PM EST, Ben Coman <
> b...@openinworld.com> wrote:
>
>
> If a valid Smalltalk method identifier contains only...
> [a-zA-Z][a-zA-Z0-9]*
> http://www.osdata.com/programming/firstprograms/valididentifiers.html
>
> then one option could be that unary symbols must touch the previous
> identifier, i.e. no intervening whitespace,
>
>   100%
>   20$
>   40€
>   12‰
>   portion%
>   someMoney$
>
>
> or pick a new "unary separator/binder"
>
>   100'%or  100 '%
>   20'$   or  20 '$
>   40'€   or  40 '€
>   12'‰ or  12 '‰
>   portion'%
>   someMoney'$
>
>
> or re-use the existing colon which indicates an argument to the right,
> to indicate an argument to the left
>
>   100 :%
>   20 :$
>   40 :€
>   12 :‰  (for promille)
>   portion :%
>   someMoney :$
>
> which is unambiguous regarding block variable definitions since no
> messages are valid in the block variable definition area,
> but this may complicate precedence semantics due to its similarity to a
> keyword selector,
> and would complicate things if the space was missing.
>
>
>
> On 18 November 2017 at 04:02, Nicolas Cellier  gmail.com> wrote:
>
>
>
> 2017-11-17 18:32 GMT+01:00 Thierry Goubier :
>
> Le 17/11/2017 à 10:14, Nicolas Cellier a écrit :
>
>
>
> 2017-11-17 17:40 GMT+01:00 Gabriel Cotelli >:
>
> I would really like to see % removed as a binary selector and
> available to use in unary or keyword ones. The only implementor in a
> Pharo 6 image is:
>
>   % aNumber
>
>  ^ self \\ aNumber
>
>
> +1, such alias has nothing to do in Kernel
>
> So it's juts aliasing \\ , and % most widespread usage in the real
> world is por percentages (the use in modular arithmetic is more a
> programming thing that math notation I think).
>
> And for allowing more Unicode code points for selector names I'm
> totally in for Symbols, Arrows, Math Symbols, etc... We just need to
> analyse the ones that makes sense as binary selectors, and the ones
> allowed for unary and keyword ones. This will allow us to write
> pretty cool DSLs.
>
> Just my opinion.
>
> This could also be the case for punctuation like ! and ?
>
> The idea of Torsten is more generic, any combination of binary char could
> be used.
>  From what I understand from https://en.wikipedia.org/wiki/ LR_parser
>  we would just have to scan one
> more token ahead for deciding if unary or binary, and could preserve our
> simple shift reduce steps...
>
>
> The Smalltalk parsers being handwritten, there wouldn't be shift/reduces
> to contend with, and, anyway, the lexer doesn't shift/reduce; it would
> simply creates a token up to the next separator (that is goble up the next
> space/cr/end of line dot/closing parenthesis/etc...)
>
>
> I don't have academical cursus, so I may be approximate, but the manually
> written parsers just have to read a single token ahead so far, and linearly
> build the parseNode, to me it was equivalent.
>
>
> So it seems doable for resolving the send.
>
>
> Sort of. The parser difficulty would be this one:
>
> anObject % print
>
>
> Yes, that's a severe limitation. Context free => it's a binary... Or we
> have to use ( ).
> But then it's unfriendly to have different rules for unary symbols versus
> unary words...
> It devaluates the idea...
>
>
>
> Is this a binary selector with a print argument or two unary selectors?
>
>
> Less ambiguous...
> anObject'% print
> anObject '% print
>
>
>
>
> Using the symbol table when you parse would solve it, but that is
> certainly not context free...
>
> More problematic would be the declaration of method, if we have both a
> unary + and a binary +, we will need new syntax for marking the difference.
>
>
>
> In most cases, distinguishing between unary + declaration and binary +
> declaration would 

[Pharo-dev] [Pharo 7.0-dev] Build #316: 20735-ComposablePresenter-classowneron-is-missing-the-initialization-call

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #316 was: SUCCESS.

The Pull Request #517 was integrated: 
"20735-ComposablePresenter-classowneron-is-missing-the-initialization-call"
Pull request url: https://github.com/pharo-project/pharo/pull/517

Issue Url: https://pharo.fogbugz.com/f/cases/20735
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/316/

Re: [Pharo-dev] Iceberg operations overview

[Cyril Ferlicot]

On Wed, Nov 22, 2017 at 9:33 AM, Pavel Krivanek
 wrote:
> Hi,
>
> during brainstorming of the Iceberg UI simplification we created a document
> that shows what the current Iceberg operations do. It should help you to
> clarify the role of the working copy etc.
>
> See the attachment.
>

Great! Can this be added to Iceberg's README on github?

Thanks!

> Note: merge uses the reference commit of the loaded version as the base.
>
> Cheers,
> -- Pavel

-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

Re: [Pharo-dev] Iceberg operations overview

[Denis Kudriashov]

Very nice. Thank's

2017-11-22 9:33 GMT+01:00 Pavel Krivanek :

> Hi,
>
> during brainstorming of the Iceberg UI simplification we created a
> document that shows what the current Iceberg operations do. It should help
> you to clarify the role of the working copy etc.
>
> See the attachment.
>
> Note: merge uses the reference commit of the loaded version as the base.
>
> Cheers,
> -- Pavel
>

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo TechTalk 21 Nov: Discord Demo

[Marcus Denker]

Hi,

I added links to the TechTalk archive:

http://pharo.org/TechTalk

> On 21 Nov 2017, at 20:02, Juraj Kubelka  wrote:
> 
> Hi,
> 
> the TechTalk record is available at the same link: 
> https://www.youtube.com/watch?v=33kXsOiP6wA 
>  
> and includes outline to simplify navigation.
> 
> Cheers,
> Juraj
> 
> 
> TechTalk Outline:
> - 01:58 The beginning of the talk
> - 04:30 Webhook
>   - 04:33 How to Create Webhook
>   - 05:39 Webhook Examples
>   - 10:33 Webhook Use Case: Script of the Day from Nautilus Code Browser
>   - 18:39 Webhook Use Case: Server Problem Notification
> - 22:45 Bot App (chatbot)
>   - 24:47 How to Create a Bot App
>   - 28:28 Bot App Examples
>   - 33:17 Bot Use Case: Source Code Expertise
> - 41:40 Standard User Client
>   - 42:57 User Client Example
>   - 45:06 User Client Use Case: Asking Directly from Pharo Playground
>   - 47:06 User Client Use Case: Receiving Questions and Answering in Pharo
>   - 50:50 Final Thoughts About Discord Integration in Inspector and Debugger
> - 52:44 Discussion
> 
>> On Nov 21, 2017, at 12:54, Juraj Kubelka > > wrote:
>> 
>> Hi!
>> 
>> The TechTalk starts in about 10 minutes. Join us on Discord, the techtalk 
>> channel.
>> 
>> Cheers,
>> Juraj
>> 
>> 
>>> On Nov 21, 2017, at 10:11, Marcus Denker >> > wrote:
>>> 
>>> The link to the live stream is this:
>>> 
>>>  https://www.youtube.com/watch?v=33kXsOiP6wA 
>>> 
>>> 
>>> It start in a bit less than 3 hours.
>>> 
>>> Marcus
>>> 
 On 18 Nov 2017, at 09:13, Marcus Denker > wrote:
 
 Pharo TechTalk: Discord Demo
 When?  21 Nov 2017 5:00 PM - 7:00 PM (UTC+01:00)
 
 Topic: "Discord communication Demo”, how to script discord from Pharo.
 
https://association.pharo.org/event-2642665 
 
>>> 
>> 
>