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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 340f1e: 30571

[GitHub]

  Branch: refs/heads/3.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 340f1ecf713d5e0ad9c662b77975cb72c6554fae
  
https://github.com/pharo-project/pharo-core/commit/340f1ecf713d5e0ad9c662b77975cb72c6554fae
  Author: Jenkins Build Server 
  Date:   2013-11-13 (Wed, 13 Nov 2013)

  Changed paths:
M 
ConfigurationCommandLineHandler-Core.package/ConfigurationCommandLineHandler.class/instance/accessing/loadRepositoryUrl.st
M 
ConfigurationCommandLineHandler-Core.package/ConfigurationCommandLineHandler.class/instance/testing/hasRepositoryUrl.st
A Files.package/SourceFileArray.class/instance/file system/close.st
A ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script227.st
A ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
updates/update30571.st
M 
ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
R 
Spec-Core.package/AbstractAdapter.class/instance/protocol/bindKeyCombination_toAction_.st
M 
Spec-Core.package/ComposableModel.class/instance/protocol-shortcuts/bindKeyCombination_toAction_.st
A 
Spec-Core.package/ComposableModel.class/instance/protocol-shortcuts/bindMenuKeyCombination_toAction_.st
A 
Spec-Core.package/ComposableModel.class/instance/protocol-shortcuts/removeKeyCombination_.st
A 
Spec-Core.package/ComposableModel.class/instance/protocol-shortcuts/removeMenuKeyCombination_.st
M 
Spec-Core.package/ComposableModel.class/instance/protocol/applyMenuModel_.st
A 
Spec-Core.package/ComposableModel.class/instance/protocol/neglectMenuModel_.st
A Spec-Core.package/MenuModel.class/instance/protocol/neglect_.st
A Spec-Core.package/NewListModel.class/class/examples/exampleWithMenu2.st
M Spec-Core.package/NewListModel.class/instance/initialize/registerEvents.st
A 
Spec-MorphicAdapters.package/AbstractMorphicAdapter.class/instance/protocol-shortcuts/bindKeyCombination_toAction_.st
A 
Spec-MorphicAdapters.package/AbstractMorphicAdapter.class/instance/protocol-shortcuts/bindMenuKeyCombination_toAction_.st
A 
Spec-MorphicAdapters.package/AbstractMorphicAdapter.class/instance/protocol-shortcuts/removeKeyCombination_.st
A 
Spec-MorphicAdapters.package/AbstractMorphicAdapter.class/instance/protocol-shortcuts/removeMenuKeyCombination_.st
M System-Support.package/SmalltalkImage.class/instance/snapshot and 
quit/shutDown.st
M System-Support.package/SmalltalkImage.class/instance/sources%2C change 
log/closeSourceFiles.st

  Log Message:
  ---
  30571
12156 Move code in SmalltalkImage>>closeSourceFiles to SourceFileArray
https://pharo.fogbugz.com/f/cases/12156

10890 Converting FileUrl w. spaces to FileReference (was Load configs from 
local folders)
https://pharo.fogbugz.com/f/cases/10890

12150 Better Menu support
https://pharo.fogbugz.com/f/cases/12150

http://files.pharo.org/image/30/30571.zip

Re: [Pharo-dev] help needed with fixing the SpecDebugger

[Tudor Girba]

Hi,

Thanks for looking into this.

However, as I wrote in the issue, the fix does not work. There are still
problems. I reopened the issue.

Cheers,
Doru


On Tue, Nov 12, 2013 at 1:15 PM, Clément Bera wrote:

> I added a slice and a comment here:
> https://pharo.fogbugz.com/f/cases/12055/
>
> Can you check if this works for you ?
>
>
> 2013/11/12 Tudor Girba 
>
>> That would be very much appreciated.
>>
>> I would also be interested in the approach you took to debug the problem.
>> It would make for a nice assessment case study.
>>
>> Cheers,
>> Doru
>>
>>
>>
>>
>> On Tue, Nov 12, 2013 at 9:50 AM, Clément Bera wrote:
>>
>>> Camillo we should have a look together.
>>>
>>> Are you at work today ?
>>>
>>>
>>> 2013/11/11 Tudor Girba 
>>>
 Hi,

 I need a bit of help with the issue of the SpecDebugger relying on the
 default inspector being implemented in Spec.

 I investigated a bit, but now I am stuck. Details here:
 https://pharo.fogbugz.com/f/cases/12055/

 Can anyone look at it?

 Cheers,
 Doru

 --
 www.tudorgirba.com

 "Every thing has its own flow"

>>>
>>>
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] Spec new release :)

[Benjamin]

So one can import a md file and turn it into pier

Ben

On 14 Nov 2013, at 02:37, Stéphane Ducasse  wrote:

>>> Is it because this is not in Pharo that this is better? May be this is a 
>>> new trend?
>> 
>> It’s because Sven ask me to point him the PEG grammar I saw for markdown.
> Ok
> 
>> And I think that Pier could benefit from a md parser
> 
> may be
> to do what? so that people can edit file with pier using mardown? in addition 
> to the pier syntax?
> May be but I do not have time for that. Now if somebody needs that the pier 
> code is MIT.
> 
>>> Now if you have the time, you can write a pier exporter and everybody will 
>>> be happy
>>> but I will not code in lua nor haskell nor ruby nor PHP.
>>> 
>>> Personally I prefer to focus on the real parts: writing good books
>>> 
>>> Stef
> 

Re: [Pharo-dev] Spec new release :)

[Nicolas Petton]

I'm just talking about class comment, writing a book is a totally
different story :)

Nico

Stéphane Ducasse writes:

> Nico
>
> when I will read a book on Amber written using the default markdown language 
> and that the book will be of decent quality, I will reconsider my position.
> Start writing (but extend markdown first because else you will get a kind of 
> book with no cross 
> ref no citation no index) so a "book" that I would not like to read and enjoy.
>
> Stef
>
>
> On Nov 14, 2013, at 1:09 AM, Nicolas Petton  wrote:
>
>> 
>> Sven Van Caekenberghe writes:
>> 
>>> It would be completely silly to have class comments in MD (no matter
>>> how cool this would be) _and_ *not* be able to have Nautilus
>>> parse/render them, with active links, etc…
>> 
>> We actually do that in the new IDE of Amber :) Then we have very nicely
>> displayed class comments.
>> 
>> Nico
>> 


-- 
Nicolas Petton
http://nicolas-petton.fr

Re: [Pharo-dev] Spec new release :)

[Stéphane Ducasse]

>> Is it because this is not in Pharo that this is better? May be this is a new 
>> trend?
> 
> It’s because Sven ask me to point him the PEG grammar I saw for markdown.
Ok

> And I think that Pier could benefit from a md parser

may be
to do what? so that people can edit file with pier using mardown? in addition 
to the pier syntax?
May be but I do not have time for that. Now if somebody needs that the pier 
code is MIT.

>> Now if you have the time, you can write a pier exporter and everybody will 
>> be happy
>> but I will not code in lua nor haskell nor ruby nor PHP.
>> 
>> Personally I prefer to focus on the real parts: writing good books
>> 
>> Stef

Re: [Pharo-dev] Spec new release :)

[Stéphane Ducasse]

Nico

when I will read a book on Amber written using the default markdown language 
and that the book will be of decent quality, I will reconsider my position.
Start writing (but extend markdown first because else you will get a kind of 
book with no cross 
ref no citation no index) so a "book" that I would not like to read and enjoy.

Stef


On Nov 14, 2013, at 1:09 AM, Nicolas Petton  wrote:

> 
> Sven Van Caekenberghe writes:
> 
>> It would be completely silly to have class comments in MD (no matter
>> how cool this would be) _and_ *not* be able to have Nautilus
>> parse/render them, with active links, etc…
> 
> We actually do that in the new IDE of Amber :) Then we have very nicely
> displayed class comments.
> 
> Nico
> 

Re: [Pharo-dev] Spec new release :)

[Benjamin]

On 14 Nov 2013, at 02:25, Stéphane Ducasse  wrote:

> Is it because this is not in Pharo that this is better? May be this is a new 
> trend?

It’s because Sven ask me to point him the PEG grammar I saw for markdown.
And I think that Pier could benefit from a md parser

> 
> Now if you have the time, you can write a pier exporter and everybody will be 
> happy
> but I will not code in lua nor haskell nor ruby nor PHP.
> 
> Personally I prefer to focus on the real parts: writing good books
> 
> Stef
> 
>> Have a look at http://jgm.github.io/lunamark/ :)
>> It may be a dirty hack, that I do not know :)
>> 
>> Ben
> 

Re: [Pharo-dev] Spec new release :)

[Stéphane Ducasse]

Is it because this is not in Pharo that this is better? May be this is a new 
trend?

Now if you have the time, you can write a pier exporter and everybody will be 
happy
but I will not code in lua nor haskell nor ruby nor PHP.

Personally I prefer to focus on the real parts: writing good books

Stef

> Have a look at http://jgm.github.io/lunamark/ :)
> It may be a dirty hack, that I do not know :)
> 
> Ben

Re: [Pharo-dev] Spec new release :)

[Stéphane Ducasse]

> 
>>> It would be completely silly to have class comments in MD (no matter how 
>>> cool this would be) _and_ *not* be able to have Nautilus parse/render them, 
>>> with active links, etc…
>> 
>> With Athens inside the image we will use the pier parser to generate a 
>> document tree and render it inside the image. 
>> Now one step at a time. 
>> 
 There are some PEG grammar for markdown, maybe it could be reused so PP 
 can parse it :)
 then one could generate Pier format out of markdown :)
>> 
>> What most of you do not get is that. But I do not care about Pier format. I 
>> care about a REAL solution that can produce a REAL document tree AND that 
>> ***I*** can edit and maintain and enhance so that I can create books.
> 
> So why not extending markdown then ?

repeat after me:
- we have a working parser + model that works and we produce books with 
it since YEARS!
- do you want to hack in haskell or whatever language - not me :)
- what is the value of an extended markdown if it is not supported by 
git tools = the same as pier syntax 
- we have a cool emacs mode for pier with big fonts for sections and 
all the rest.
- we have a pier cms with pier syntax, so if we want we can even write 
directly on the web.
Lukas and me wrote the seaside book like that after latex and XML.
- we have a latex exporter for pier domain
- we have a html exporter for pier domain
- we have nice visitors
so why should I hack a non standard under specified language without a decent 
debugger in 
a language that I do not want to learn?

I prefer to concentrate on writing books and coding more important 
things.

Now if you want you can try your own way and create a pier exporter so that 
your documentation find its way 
in our books. But I will not do it.

Stef

Re: [Pharo-dev] Spec new release :)

[Stéphane Ducasse]

>> 
>>> Why not generating markdown code from pier code?
>>> If the whole problem is exposure on the web. Someone has considered 
>>> pdf2html or latex2html?
>> 
>> I did => suicidal tendencies.
>> The results looks like shit.
>> 
>> I did not try pdf2html.
>> 
>> Now pier is a compromise so that normal people can write chapter without 
>> being a latex freaks like us.
>> 
>> Stef
> 
> That’s also the thing, md is designed in a (shitty) way so one does not have 
> to “learn” it since it’s is “close” 
> to what one will write in an email

did you check pier syntax?
how far it is from markdown?
why is it a wiki syntax? remember wiki means fast
do you think that I did not think about it?

Ignacio already wrote 5 pages of calculator spec and I do not think that it 
took him more that 10 min 
to get the syntax. Some details should be remembered but the main is dead 
simple.

Re: [Pharo-dev] Spec new release :)

[Stéphane Ducasse]

On Nov 14, 2013, at 1:03 AM, Benjamin  
wrote:

> On 13 Nov 2013, at 20:40, Stéphane Ducasse  wrote:
> 
>> So read the thread that yuriy rasied last week
>> my sumarry
>>  - write in pier 
>>  publish in latex, html, markdong
> 
> “markdong” ? that’s a chinese variant :P

;P
yes 
400 × 195 - baudelet.net
vietnamese apparently 

> For md, there is pandoc (http://johnmacfarlane.net/pandoc/)
> it converts a lot of format into a lot of other formats :)

Yes we know. But again as I said it one million times. Markdown does not offer 
what is needed to write books.
I will not repeat here. And I will not hack pandoc to make it works.

> 
>>  - too many variation of markdown
>>  - do not want to ask in haskell, ruby… to extend libraries
> 
> I do not get it

>> - do not want to **hack** in haskell, ruby… to extend libraries

> 
>>  - markdown does not support references and other essential points for 
>> making decent books
> 
> What do you mean by "references and other essential points” ?

I will not repeat it :)
Read the thread of yuriy.


> 
> Ben
> 
>>  
>> Stef
>> 
>> 
>> On Nov 13, 2013, at 7:59 PM, Benjamin  
>> wrote:
>> 
>>> It was a real question, and it feels like you overreacted the answer …
>>> 
>>> To me, markdown or pier is a new syntax to learn so I am asking …
>>> To me, doing Pier because you do or because you said to is no really an 
>>> argument.
>>> 
>>> Then I am open to a real answer but I also see that markdown is integrated 
>>> to a lot of tools (github and jekylls by examples)
>>> and that a lot of people knows about markdown.
>>> 
>>> This was a real question, not a troll ...
>>> 
>>> Ben
>>> 
>>> On 13 Nov 2013, at 19:22, Stéphane Ducasse  
>>> wrote:
>>> 
 do you really think that I insist of using pier syntax because
A- I want to lose my time
B- this is for my ego?
C- because I'm funny
D- ...
 
 No seriously?
 
 If you want to get an answer read the thread that yuri raised a while ago.
 Because we already discussed discussed and discussed it.
 
 I will not write any book in markdown. Now you can try and we see.
 
 Stef
 
> Stef, what is the advantages of writing it in Pier compared to markdown ?
> 
> Ben
> 
 
 
>>> 
>> 
> 

Re: [Pharo-dev] Spec new release :)

[Nicolas Petton]

Sven Van Caekenberghe writes:

> It would be completely silly to have class comments in MD (no matter
> how cool this would be) _and_ *not* be able to have Nautilus
> parse/render them, with active links, etc…

We actually do that in the new IDE of Amber :) Then we have very nicely
displayed class comments.

Nico

Re: [Pharo-dev] Spec new release :)

[Benjamin]

Have a look at http://jgm.github.io/lunamark/ :)
It may be a dirty hack, that I do not know :)

Ben

On 13 Nov 2013, at 20:27, Sven Van Caekenberghe  wrote:

> 
> On 13 Nov 2013, at 20:22, Benjamin  
> wrote:
> 
>> On 13 Nov 2013, at 20:05, Sven Van Caekenberghe  wrote:
>> 
>>> 
>>> On 13 Nov 2013, at 19:59, Benjamin  
>>> wrote:
>>> 
 It was a real question, and it feels like you overreacted the answer …
 
 To me, markdown or pier is a new syntax to learn so I am asking …
 To me, doing Pier because you do or because you said to is no really an 
 argument.
 
 Then I am open to a real answer but I also see that markdown is integrated 
 to a lot of tools (github and jekylls by examples)
 and that a lot of people knows about markdown.
 
 This was a real question, not a troll …
>>> 
>>> I like .md as well and yes, the github integration makes it compelling.
>>> 
>>> But one objective argument against Markdown and in favour of Pier is that 
>>> the former has no good parser and/or document model and and the latter does 
>>> have both, in Pharo. That means that we can write all sorts of tools 
>>> ourselves and get things finished, as was proven with the books.
>>> 
>>> There simply isn’t any definitive, unambiguous Markdown syntax (the github 
>>> variant is only one version).
>> 
>> Ok :)
>> But as an end user, do you feel the difference ?
> 
> I know, but the documentation is meant to be integrated in the Pharo 
> ecosystem.
> 
> It would be completely silly to have class comments in MD (no matter how cool 
> this would be) _and_ *not* be able to have Nautilus parse/render them, with 
> active links, etc…
> 
>> There are some PEG grammar for markdown, maybe it could be reused so PP can 
>> parse it :)
>> then one could generate Pier format out of markdown :)
> 
> So indeed, that is what we need. [And what we already have for Pier].
> But be sure to ask Camillo how his 2 attempts went before you get ambitious.
> I look at the PP MD code and thought, I can do better, but after writing some 
> actual code, I stopped ;-)
> 
> BTW, please point me to grammar, I never found one ! Each MD parser is one 
> big hack.
> 
>> Ben
>> 
>>> 
 Ben
 
 On 13 Nov 2013, at 19:22, Stéphane Ducasse  
 wrote:
 
> do you really think that I insist of using pier syntax because
>   A- I want to lose my time
>   B- this is for my ego?
>   C- because I'm funny
>   D- ...
> 
> No seriously?
> 
> If you want to get an answer read the thread that yuri raised a while ago.
> Because we already discussed discussed and discussed it.
> 
> I will not write any book in markdown. Now you can try and we see.
> 
> Stef
> 
>> Stef, what is the advantages of writing it in Pier compared to markdown ?
>> 
>> Ben

Re: [Pharo-dev] Spec new release :)

[Benjamin]

On 13 Nov 2013, at 21:19, Stéphane Ducasse  wrote:

>> It would be completely silly to have class comments in MD (no matter how 
>> cool this would be) _and_ *not* be able to have Nautilus parse/render them, 
>> with active links, etc…
> 
> With Athens inside the image we will use the pier parser to generate a 
> document tree and render it inside the image. 
> Now one step at a time. 
> 
>>> There are some PEG grammar for markdown, maybe it could be reused so PP can 
>>> parse it :)
>>> then one could generate Pier format out of markdown :)
> 
> What most of you do not get is that. But I do not care about Pier format. I 
> care about a REAL solution that can produce a REAL document tree AND that 
> ***I*** can edit and maintain and enhance so that I can create books.

So why not extending markdown then ?


Ben


> So I'm pragmatic we wrote the seaside book with pier so I took pier because I 
> do not want to write a MD parser and building model
> and reinventing the wheel. And I do not want to have to learn a new language 
> just to make sure that I can write books.
> 
> Stef
> 
> 

Re: [Pharo-dev] Spec new release :)

[Benjamin]

On 13 Nov 2013, at 20:40, Stéphane Ducasse  wrote:

> So read the thread that yuriy rasied last week
> my sumarry
>   - write in pier 
>   publish in latex, html, markdong

“markdong” ? that’s a chinese variant :P
For md, there is pandoc (http://johnmacfarlane.net/pandoc/)
it converts a lot of format into a lot of other formats :)

>   - too many variation of markdown
>   - do not want to ask in haskell, ruby… to extend libraries

I do not get it

>   - markdown does not support references and other essential points for 
> making decent books

What do you mean by "references and other essential points” ?

Ben

>   
> Stef
> 
> 
> On Nov 13, 2013, at 7:59 PM, Benjamin  
> wrote:
> 
>> It was a real question, and it feels like you overreacted the answer …
>> 
>> To me, markdown or pier is a new syntax to learn so I am asking …
>> To me, doing Pier because you do or because you said to is no really an 
>> argument.
>> 
>> Then I am open to a real answer but I also see that markdown is integrated 
>> to a lot of tools (github and jekylls by examples)
>> and that a lot of people knows about markdown.
>> 
>> This was a real question, not a troll ...
>> 
>> Ben
>> 
>> On 13 Nov 2013, at 19:22, Stéphane Ducasse  wrote:
>> 
>>> do you really think that I insist of using pier syntax because
>>> A- I want to lose my time
>>> B- this is for my ego?
>>> C- because I'm funny
>>> D- ...
>>> 
>>> No seriously?
>>> 
>>> If you want to get an answer read the thread that yuri raised a while ago.
>>> Because we already discussed discussed and discussed it.
>>> 
>>> I will not write any book in markdown. Now you can try and we see.
>>> 
>>> Stef
>>> 
 Stef, what is the advantages of writing it in Pier compared to markdown ?
 
 Ben
 
>>> 
>>> 
>> 
> 

Re: [Pharo-dev] Spec new release :)

[Benjamin]

That would be appreciated :)

Ben

On 13 Nov 2013, at 21:18, kilon alios  wrote:

> Stephane I think you need to sit down and write the Guidelines for Pharo 
> Documentation, explaining the tools, the workflow, the goals, the principles 
> and most importantly where documentation can be found. Post it on pharo 
> website. This way you will save a lot of time from answering questions here . 
> So next time someone asks a relevant question you only post a link to it. 
> 
> 
> 
> 
> On Wed, Nov 13, 2013 at 9:44 PM, Stéphane Ducasse  
> wrote:
> 
> On Nov 13, 2013, at 8:22 PM, Alexandre Bergel  wrote:
> 
> > Why not generating markdown code from pier code?
> > If the whole problem is exposure on the web. Someone has considered 
> > pdf2html or latex2html?
> 
> I did => suicidal tendencies.
> The results looks like shit.
> 
> I did not try pdf2html.
> 
> Now pier is a compromise so that normal people can write chapter without 
> being a latex freaks like us.
> 
> Stef
> 
> 
> > Maybe my question is naive, I do not know.
> >
> > On some point, i have tried to generate the roassal documentation from the 
> > Roassal Help, but it makes the maintenance loop heavy: If I want to fix 
> > something in the text, I had to edit the Help in Pharo, generating the 
> > document, compiling into .pdf. Quite heavy it was. At the end, I only 
> > worked on the .tex files.
> >
> > Alexandre
> >
> >
> > On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe  wrote:
> >
> >>
> >> On 13 Nov 2013, at 19:59, Benjamin  
> >> wrote:
> >>
> >>> It was a real question, and it feels like you overreacted the answer …
> >>>
> >>> To me, markdown or pier is a new syntax to learn so I am asking …
> >>> To me, doing Pier because you do or because you said to is no really an 
> >>> argument.
> >>>
> >>> Then I am open to a real answer but I also see that markdown is 
> >>> integrated to a lot of tools (github and jekylls by examples)
> >>> and that a lot of people knows about markdown.
> >>>
> >>> This was a real question, not a troll …
> >>
> >> I like .md as well and yes, the github integration makes it compelling.
> >>
> >> But one objective argument against Markdown and in favour of Pier is that 
> >> the former has no good parser and/or document model and and the latter 
> >> does have both, in Pharo. That means that we can write all sorts of tools 
> >> ourselves and get things finished, as was proven with the books.
> >>
> >> There simply isn’t any definitive, unambiguous Markdown syntax (the github 
> >> variant is only one version).
> >>
> >>> Ben
> >>>
> >>> On 13 Nov 2013, at 19:22, Stéphane Ducasse  
> >>> wrote:
> >>>
>  do you really think that I insist of using pier syntax because
> A- I want to lose my time
> B- this is for my ego?
> C- because I'm funny
> D- ...
> 
>  No seriously?
> 
>  If you want to get an answer read the thread that yuri raised a while 
>  ago.
>  Because we already discussed discussed and discussed it.
> 
>  I will not write any book in markdown. Now you can try and we see.
> 
>  Stef
> 
> > Stef, what is the advantages of writing it in Pier compared to markdown 
> > ?
> >
> > Ben
> >
> 
> 
> >>>
> >>
> >>
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
> 
> 
> 

Re: [Pharo-dev] Spec new release :)

[Benjamin]

On 13 Nov 2013, at 20:44, Stéphane Ducasse  wrote:

> 
> On Nov 13, 2013, at 8:22 PM, Alexandre Bergel  wrote:
> 
>> Why not generating markdown code from pier code?
>> If the whole problem is exposure on the web. Someone has considered pdf2html 
>> or latex2html?
> 
> I did => suicidal tendencies.
> The results looks like shit.
> 
> I did not try pdf2html.
> 
> Now pier is a compromise so that normal people can write chapter without 
> being a latex freaks like us.
> 
> Stef

That’s also the thing, md is designed in a (shitty) way so one does not have to 
“learn” it since it’s is “close” 
to what one will write in an email

Ben

> 
> 
>> Maybe my question is naive, I do not know.
>> 
>> On some point, i have tried to generate the roassal documentation from the 
>> Roassal Help, but it makes the maintenance loop heavy: If I want to fix 
>> something in the text, I had to edit the Help in Pharo, generating the 
>> document, compiling into .pdf. Quite heavy it was. At the end, I only worked 
>> on the .tex files.
>> 
>> Alexandre
>> 
>> 
>> On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe  wrote:
>> 
>>> 
>>> On 13 Nov 2013, at 19:59, Benjamin  
>>> wrote:
>>> 
 It was a real question, and it feels like you overreacted the answer …
 
 To me, markdown or pier is a new syntax to learn so I am asking …
 To me, doing Pier because you do or because you said to is no really an 
 argument.
 
 Then I am open to a real answer but I also see that markdown is integrated 
 to a lot of tools (github and jekylls by examples)
 and that a lot of people knows about markdown.
 
 This was a real question, not a troll …
>>> 
>>> I like .md as well and yes, the github integration makes it compelling.
>>> 
>>> But one objective argument against Markdown and in favour of Pier is that 
>>> the former has no good parser and/or document model and and the latter does 
>>> have both, in Pharo. That means that we can write all sorts of tools 
>>> ourselves and get things finished, as was proven with the books.
>>> 
>>> There simply isn’t any definitive, unambiguous Markdown syntax (the github 
>>> variant is only one version).
>>> 
 Ben
 
 On 13 Nov 2013, at 19:22, Stéphane Ducasse  
 wrote:
 
> do you really think that I insist of using pier syntax because
>   A- I want to lose my time
>   B- this is for my ego?
>   C- because I'm funny
>   D- ...
> 
> No seriously?
> 
> If you want to get an answer read the thread that yuri raised a while ago.
> Because we already discussed discussed and discussed it.
> 
> I will not write any book in markdown. Now you can try and we see.
> 
> Stef
> 
>> Stef, what is the advantages of writing it in Pier compared to markdown ?
>> 
>> Ben
>> 
> 
> 
 
>>> 
>>> 
>> 
>> -- 
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> 
>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] Spec new release :)

[Stéphane Ducasse]

>>> It would be completely silly to have class comments in MD (no matter how 
>>> cool this would be) _and_ *not* be able to have Nautilus parse/render them, 
>>> with active links, etc…
>> 
>> With Athens inside the image we will use the pier parser to generate a 
>> document tree and render it inside the image. 
> 
> What has this to do with athens? 

I want really nice font so this is not really related to athens and was 
confused. 

> We already have a prototype implementation with Markdown using the existing 
> text model. Worked already fine, so that should be 1 afternoon of work to get 
> the pier syntax running in the current image.

Where it is? that we add it to our todo?
because having a real domain model (which we have) is the way to go. I do not 
want to hack stuff.
Now we ***HAVE*** a fully working pier parser and creating domain and we ARE 
enhancing it already.  

Stef

Re: [Pharo-dev] Spec new release :)

[Benjamin]

I ask Damien Cassou this morning about that.

He told me it should be quite easy to do :)
(just another visitor I guess)

Ben

On 13 Nov 2013, at 20:28, Sven Van Caekenberghe  wrote:

> 
> On 13 Nov 2013, at 20:22, Alexandre Bergel  wrote:
> 
>> Why not generating markdown code from pier code?
>> If the whole problem is exposure on the web. Someone has considered pdf2html 
>> or latex2html? Maybe my question is naive, I do not know.
> 
> It is not silly, and yes it could be done quite easily I guess, if it even 
> has not yet been done already. 
> 
>> On some point, i have tried to generate the roassal documentation from the 
>> Roassal Help, but it makes the maintenance loop heavy: If I want to fix 
>> something in the text, I had to edit the Help in Pharo, generating the 
>> document, compiling into .pdf. Quite heavy it was. At the end, I only worked 
>> on the .tex files.
>> 
>> Alexandre
>> 
>> 
>> On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe  wrote:
>> 
>>> 
>>> On 13 Nov 2013, at 19:59, Benjamin  
>>> wrote:
>>> 
 It was a real question, and it feels like you overreacted the answer …
 
 To me, markdown or pier is a new syntax to learn so I am asking …
 To me, doing Pier because you do or because you said to is no really an 
 argument.
 
 Then I am open to a real answer but I also see that markdown is integrated 
 to a lot of tools (github and jekylls by examples)
 and that a lot of people knows about markdown.
 
 This was a real question, not a troll …
>>> 
>>> I like .md as well and yes, the github integration makes it compelling.
>>> 
>>> But one objective argument against Markdown and in favour of Pier is that 
>>> the former has no good parser and/or document model and and the latter does 
>>> have both, in Pharo. That means that we can write all sorts of tools 
>>> ourselves and get things finished, as was proven with the books.
>>> 
>>> There simply isn’t any definitive, unambiguous Markdown syntax (the github 
>>> variant is only one version).
>>> 
 Ben
 
 On 13 Nov 2013, at 19:22, Stéphane Ducasse  
 wrote:
 
> do you really think that I insist of using pier syntax because
>   A- I want to lose my time
>   B- this is for my ego?
>   C- because I'm funny
>   D- ...
> 
> No seriously?
> 
> If you want to get an answer read the thread that yuri raised a while ago.
> Because we already discussed discussed and discussed it.
> 
> I will not write any book in markdown. Now you can try and we see.
> 
> Stef
> 
>> Stef, what is the advantages of writing it in Pier compared to markdown ?
>> 
>> Ben
>> 
> 
> 
 
>>> 
>>> 
>> 
>> -- 
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> 
>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

[Nicolas Cellier]

Of course, since this is a question of style, all was invented way before
the computer era :)
https://en.wikipedia.org/wiki/Metonymy#Synecdoche


2013/11/13 Chris Muller 

> These are really excellent arguments, Nicolas.  Good discussion.
>
> On Wed, Nov 13, 2013 at 3:32 PM, Nicolas Cellier
>  wrote:
> > Chris,
> > I have to completely disagree.
> > The idea of breaking a complex object into simpler parts is not just
> > theories and extremism.
> > Assigning several roles to an object is sometimes convenient for a start,
> > but generally does scale very badly.
> > It's a collective experience driven by pragmatic considerations in
> > developping in all sort of languages.
> > And it's my own experience too.
> >
> > A file is like the container, the stream is about reading/writing the
> > contents.
> > I think I remember the confusion was made at the beginning in st-80,
> because
> > it was simple enough at that time.
> > So it's rather an historical slag, not something that was added later for
> > this special case.
> > And it is something that should have been revised, because when we added
> > pipes, sockets or other external streams, that ruined the idea of
> confusing
> > the two things into a not well delimited blob without clear
> > responsibilities.
> > Though we kept the original implementation and started to distort the
> > package by adding faked polymorphism like name ^'john doe'.
> >
> > Clearly, I need no stream on its contents to rename a file, query its
> > permissions, or delete it, so why bother with internal states of a
> stream if
> > I'm interested in handling the file?
> > If I am interested about the contents, I don't need to ever know about
> the
> > path of the file nor its name, or shall I change a $A read from it into
> a $B
> > if the file is named 'turnAllAinB'?
> >
> > Where exactly are we going to need this encapsulated blob which pretend
> to
> > be both a file and a stream? I would be happy to show that a rewrite is
> both
> > simple and good looking at end application sites.
> > Of course, inside the lava of multi year hacked stream hierarchy, it
> might
> > be a bit less obvious to disentangle the spaghetti.
> > Hence more radical solutions: table rase and complete rewrite.
> >
> >
> >
> >
> >
> > 2013/11/13 Chris Muller 
> >>
> >> On Wed, Nov 13, 2013 at 1:17 PM, Nicolas Cellier
> >>  wrote:
> >> > Exactly, every specialized stream has its specialized API and/or
> >> > specialized
> >> > implementation.
> >> > File streams don't even have a name, because they need not to.
> >> > You can browse XTFileReadStream and XTFileWriteStream, you won't find
> >> > such
> >> > thing.
> >> > The file has a name, the stream does not need any.
> >> > Before adding anything to a stream, ask first, why am i going to need
> >> > this?
> >>
> >> I agree with what Frank said, but not your suggestion that:
> >>
> >> > File streams don't even have a name, because they need not to.
> >> > If it really need it, the application certainly can retrieve the name
> >> > from a higher level object (a
> >> > FIleReference, FileDirectory or whatever).
> >>
> >> because doing that means the FileStream is no longer
> >> fully-encapsulated.  And now for the same method to support a
> >> non-FileStream stream, what will be passed as the new FileReference
> >> argument?  nil?  So the code went from stream-delegation to
> >> case-logic.
> >>
> >> This is why organic growth happened in the original Stream hierarchy
> >> -- because it was "needed", not random.  Not strict, yes, but not
> >> "random" either.
> >>
> >> One final thing to consider about selector "uniformity" is how it can
> >> negate the ability to effectively trace code (via senders and
> >> implementors).  Wow, how many senders of #next...?
> >>
> >> Stream-composition is cool, though, and I understand that to be a
> >> benefit of the stricter API.
> >>
> >>
> >>
> >> > 2013/11/13 Frank Shearar 
> >> >>
> >> >> On 13 November 2013 16:48, Chris Muller  wrote:
> >> >> > I know nothing about Xtreams but, IMO, this obsession with
> sterility
> >> >> > borders on mental illness.
> >> >> >
> >> >> > "All sort of un-needed complexity?"  That's overstating it a bit,
> >> >> > don't you think?
> >> >> >
> >> >> > So you must really feel stressed that ALL Object's, in fact, have a
> >> >> > #name, huh?  I admit this seems to push the limits but...
> >> >> >
> >> >> > what's the point of having any kind of different streams at all
> then?
> >> >> > It's the _differences_ between them that makes composing them
> useful.
> >> >> > Compression, encryption, filtering, sockets, files, circular, etc.
> >> >> > You think you'll be able to do all that and get away with all of
> them
> >> >> > having exactly the same API?
> >> >>
> >> >> They don't have the same API. And they shouldn't. And that's Nicolas'
> >> >> whole point. A Stream does not have a name (nor should it - what's
> the
> >> >> name of the compressed output of an audio stream from your
> >> >> micr

Re: [Pharo-dev] Spec new release :)

[Jan Vrany]

We already have a prototype implementation with Markdown using the
existing text model.Worked already fine,


Where can I find it? I'm quite interested.

Jan

Re: [Pharo-dev] Spec new release :)

[Camillo Bruni]

On 2013-11-13, at 21:19, Stéphane Ducasse  wrote:

>> It would be completely silly to have class comments in MD (no matter how 
>> cool this would be) _and_ *not* be able to have Nautilus parse/render them, 
>> with active links, etc…
> 
> With Athens inside the image we will use the pier parser to generate a 
> document tree and render it inside the image. 

What has this to do with athens? 
We already have a prototype implementation with Markdown using the existing 
text model. Worked already fine, so that should be 1 afternoon of work to get 
the pier syntax running in the current image.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] Spec new release :)

[Camillo Bruni]

On 2013-11-13, at 22:26, Stéphane Ducasse  wrote:

> I will write and send a proposal to the list. Good idea.

... and put it in the documentation repository, I thought of gathering the 
documentation
there, centralized, transparent open for contributions from everybody.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

[Chris Muller]

These are really excellent arguments, Nicolas.  Good discussion.

On Wed, Nov 13, 2013 at 3:32 PM, Nicolas Cellier
 wrote:
> Chris,
> I have to completely disagree.
> The idea of breaking a complex object into simpler parts is not just
> theories and extremism.
> Assigning several roles to an object is sometimes convenient for a start,
> but generally does scale very badly.
> It's a collective experience driven by pragmatic considerations in
> developping in all sort of languages.
> And it's my own experience too.
>
> A file is like the container, the stream is about reading/writing the
> contents.
> I think I remember the confusion was made at the beginning in st-80, because
> it was simple enough at that time.
> So it's rather an historical slag, not something that was added later for
> this special case.
> And it is something that should have been revised, because when we added
> pipes, sockets or other external streams, that ruined the idea of confusing
> the two things into a not well delimited blob without clear
> responsibilities.
> Though we kept the original implementation and started to distort the
> package by adding faked polymorphism like name ^'john doe'.
>
> Clearly, I need no stream on its contents to rename a file, query its
> permissions, or delete it, so why bother with internal states of a stream if
> I'm interested in handling the file?
> If I am interested about the contents, I don't need to ever know about the
> path of the file nor its name, or shall I change a $A read from it into a $B
> if the file is named 'turnAllAinB'?
>
> Where exactly are we going to need this encapsulated blob which pretend to
> be both a file and a stream? I would be happy to show that a rewrite is both
> simple and good looking at end application sites.
> Of course, inside the lava of multi year hacked stream hierarchy, it might
> be a bit less obvious to disentangle the spaghetti.
> Hence more radical solutions: table rase and complete rewrite.
>
>
>
>
>
> 2013/11/13 Chris Muller 
>>
>> On Wed, Nov 13, 2013 at 1:17 PM, Nicolas Cellier
>>  wrote:
>> > Exactly, every specialized stream has its specialized API and/or
>> > specialized
>> > implementation.
>> > File streams don't even have a name, because they need not to.
>> > You can browse XTFileReadStream and XTFileWriteStream, you won't find
>> > such
>> > thing.
>> > The file has a name, the stream does not need any.
>> > Before adding anything to a stream, ask first, why am i going to need
>> > this?
>>
>> I agree with what Frank said, but not your suggestion that:
>>
>> > File streams don't even have a name, because they need not to.
>> > If it really need it, the application certainly can retrieve the name
>> > from a higher level object (a
>> > FIleReference, FileDirectory or whatever).
>>
>> because doing that means the FileStream is no longer
>> fully-encapsulated.  And now for the same method to support a
>> non-FileStream stream, what will be passed as the new FileReference
>> argument?  nil?  So the code went from stream-delegation to
>> case-logic.
>>
>> This is why organic growth happened in the original Stream hierarchy
>> -- because it was "needed", not random.  Not strict, yes, but not
>> "random" either.
>>
>> One final thing to consider about selector "uniformity" is how it can
>> negate the ability to effectively trace code (via senders and
>> implementors).  Wow, how many senders of #next...?
>>
>> Stream-composition is cool, though, and I understand that to be a
>> benefit of the stricter API.
>>
>>
>>
>> > 2013/11/13 Frank Shearar 
>> >>
>> >> On 13 November 2013 16:48, Chris Muller  wrote:
>> >> > I know nothing about Xtreams but, IMO, this obsession with sterility
>> >> > borders on mental illness.
>> >> >
>> >> > "All sort of un-needed complexity?"  That's overstating it a bit,
>> >> > don't you think?
>> >> >
>> >> > So you must really feel stressed that ALL Object's, in fact, have a
>> >> > #name, huh?  I admit this seems to push the limits but...
>> >> >
>> >> > what's the point of having any kind of different streams at all then?
>> >> > It's the _differences_ between them that makes composing them useful.
>> >> > Compression, encryption, filtering, sockets, files, circular, etc.
>> >> > You think you'll be able to do all that and get away with all of them
>> >> > having exactly the same API?
>> >>
>> >> They don't have the same API. And they shouldn't. And that's Nicolas'
>> >> whole point. A Stream does not have a name (nor should it - what's the
>> >> name of the compressed output of an audio stream from your
>> >> microphone?). A FileStream can extend this API, and that's fine. But
>> >> keep that out of the Stream API.
>> >>
>> >> So Nicolas is arguing that _difference_ should be reflected in the
>> >> API. File streams have names, but generic streams do not.
>> >>
>> >> As it happens, Xtreams takes a very disciplined approach to this. Some
>> >> streams have positions, and so you can go back. Some can't. This is
>> >> ref

Re: [Pharo-dev] Spec new release :)

[Norbert Hartl]

> Am 13.11.2013 um 19:22 schrieb Stéphane Ducasse :
> 
>C- because I'm funny

My bet would go on this option :)

Norbert

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

[Nicolas Cellier]

Chris,
I have to completely disagree.
The idea of breaking a complex object into simpler parts is not just
theories and extremism.
Assigning several roles to an object is sometimes convenient for a start,
but generally does scale very badly.
It's a collective experience driven by pragmatic considerations in
developping in all sort of languages.
And it's my own experience too.

A file is like the container, the stream is about reading/writing the
contents.
I think I remember the confusion was made at the beginning in st-80,
because it was simple enough at that time.
So it's rather an historical slag, not something that was added later for
this special case.
And it is something that should have been revised, because when we added
pipes, sockets or other external streams, that ruined the idea of confusing
the two things into a not well delimited blob without clear
responsibilities.
Though we kept the original implementation and started to distort the
package by adding faked polymorphism like name ^'john doe'.

Clearly, I need no stream on its contents to rename a file, query its
permissions, or delete it, so why bother with internal states of a stream
if I'm interested in handling the file?
If I am interested about the contents, I don't need to ever know about the
path of the file nor its name, or shall I change a $A read from it into a
$B if the file is named 'turnAllAinB'?

Where exactly are we going to need this encapsulated blob which pretend to
be both a file and a stream? I would be happy to show that a rewrite is
both simple and good looking at end application sites.
Of course, inside the lava of multi year hacked stream hierarchy, it might
be a bit less obvious to disentangle the spaghetti.
Hence more radical solutions: table rase and complete rewrite.





2013/11/13 Chris Muller 

> On Wed, Nov 13, 2013 at 1:17 PM, Nicolas Cellier
>  wrote:
> > Exactly, every specialized stream has its specialized API and/or
> specialized
> > implementation.
> > File streams don't even have a name, because they need not to.
> > You can browse XTFileReadStream and XTFileWriteStream, you won't find
> such
> > thing.
> > The file has a name, the stream does not need any.
> > Before adding anything to a stream, ask first, why am i going to need
> this?
>
> I agree with what Frank said, but not your suggestion that:
>
> > File streams don't even have a name, because they need not to.
> > If it really need it, the application certainly can retrieve the name
> from a higher level object (a
> > FIleReference, FileDirectory or whatever).
>
> because doing that means the FileStream is no longer
> fully-encapsulated.  And now for the same method to support a
> non-FileStream stream, what will be passed as the new FileReference
> argument?  nil?  So the code went from stream-delegation to
> case-logic.
>
> This is why organic growth happened in the original Stream hierarchy
> -- because it was "needed", not random.  Not strict, yes, but not
> "random" either.
>
> One final thing to consider about selector "uniformity" is how it can
> negate the ability to effectively trace code (via senders and
> implementors).  Wow, how many senders of #next...?
>
> Stream-composition is cool, though, and I understand that to be a
> benefit of the stricter API.
>
>
>
> > 2013/11/13 Frank Shearar 
> >>
> >> On 13 November 2013 16:48, Chris Muller  wrote:
> >> > I know nothing about Xtreams but, IMO, this obsession with sterility
> >> > borders on mental illness.
> >> >
> >> > "All sort of un-needed complexity?"  That's overstating it a bit,
> >> > don't you think?
> >> >
> >> > So you must really feel stressed that ALL Object's, in fact, have a
> >> > #name, huh?  I admit this seems to push the limits but...
> >> >
> >> > what's the point of having any kind of different streams at all then?
> >> > It's the _differences_ between them that makes composing them useful.
> >> > Compression, encryption, filtering, sockets, files, circular, etc.
> >> > You think you'll be able to do all that and get away with all of them
> >> > having exactly the same API?
> >>
> >> They don't have the same API. And they shouldn't. And that's Nicolas'
> >> whole point. A Stream does not have a name (nor should it - what's the
> >> name of the compressed output of an audio stream from your
> >> microphone?). A FileStream can extend this API, and that's fine. But
> >> keep that out of the Stream API.
> >>
> >> So Nicolas is arguing that _difference_ should be reflected in the
> >> API. File streams have names, but generic streams do not.
> >>
> >> As it happens, Xtreams takes a very disciplined approach to this. Some
> >> streams have positions, and so you can go back. Some can't. This is
> >> reflected in the API. This is good.
> >>
> >> > IMHO working around that, passing extra objects around, sounds more
> >> > stressful than letting a stream on a _file_ know its filename..
> >>
> >> Mu. Streams have no names. File streams have names.
> >>
> >> frank
> >>
> >> >> If 

Re: [Pharo-dev] Instrumenting field accesses with Opal?

[Stéphane Ducasse]

>>> Hi!
>>> 
>>> Is there a way to get notified when fields are accessed?
>>> That would be awesome
>> 
>> You can use the current reflectivity prototype. It's on RMoD CI: 
>> https://ci.inria.fr/rmod/job/Reflectivity/
>> It should look like something like that:
>> 
>> YourClass methods do: [ :method |
>>  method ast 
>>  forAllNodes: [ :node | node isVariable and: [ node isInstance ] 
>> ]
>>  putAfter: [ RFMetalink expression: 'Transcript crShow: ''iv 
>> accessed''' ];
>>  installWrapper ].
> 
> In the end we should be able to just use the Slot MOP ;)
so cool 
:)

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

[Stéphane Ducasse]

thanks for this discussion it is interesting. 
I like small api fully implemented vs large and bogus ones

Stef

On Nov 13, 2013, at 6:47 PM, Nicolas Cellier 
 wrote:

> 
> -- Forwarded message --
> From: Nicolas Cellier 
> Date: 2013/11/13
> Subject: Re: [Pharo-dev] In-memory FileSystem write streams not being 
> polymorphic
> 
> The long answer is simple: the more responsibility you put in Stream, the 
> more complexity you get.
> The first complexity that I'm speaking of is non-uniformity and random 
> implementation (or un-implementation) of a set of features.
> I mean some streams in the huge hierarchy implement only half of the 
> contract, but hey, what was the contract exactly?
> Ah, yes, there were no contract, just hacks left here and there randomly and 
> concurrently in a big hierarchy.
> I add a new subclass, but don't implement all the features, there are too 
> many of them, and I don't know them all..
> I add a new feature, but don't implement it in all the classes, there are too 
> many of them, and I don't know them all.
> This procedure invariably ends up with a blob of un-maintanable code, were 
> two stream would not even agree on upToEnd behavior - I think you remember it 
> :)
> 
> If the goal is to replicate all the accumulated responsibilities of Squeak 
> Streams, but with a clarified contract, I think this is a dead end: too much 
> cruft to support, too many features, too many undefined or not well defined 
> behaviors to be clarified.
> 
> Xtreams takes the opposite path: concentrate on constructing a common, simple 
> and uniform API, concerning streams, just basic stream methods.
> Some specialized streams then implement some specialized behavior, and you 
> can compose them (by wrapping) when you need the specific API.
> This way, you ain't got to implement/maintain feature A into a few dozen of 
> classes.
> And your brand new SpecialFeatureBStream only has to implement a few well 
> known behaviours and your Special Feature B.
> 
> The short answer is even more simple : a stream does not have a name, like a 
> collection does not have a name, because we ain't gonna need it.
> If we really need a name, then we'll create a XTNamedReadStream and a 
> XTNamedWriteStream responding to #name, but I doubt we'll do.
> 
> 
> 2013/11/13 Chris Muller 
> On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier 
>  wrote:
> Yes, a Wrapper would provide the legacy API.
> 
> And yes, the name of a stream should better not be part of the API.
> Most stream don't have a name, and adding such API adds all sort of un-needed 
> complexity.
> It's an internal detail that can eventually help for reporting error if 
> accessible, but nothing more.
> 
>  
> I know nothing about Xtreams but, IMO, this obsession with sterility borders 
> on mental illness.
> 
> "All sort of un-needed complexity?"  That's overstating it a bit, don't you 
> think?
> 
> So you must really feel stressed that ALL Object's, in fact, have a #name, 
> huh?  I admit this seems to push the limits but... 
> 
> what's the point of having any kind of different streams at all then?  It's 
> the _differences_ between them that makes composing them useful.  
> Compression, encryption, filtering, sockets, files, circular, etc.  You think 
> you'll be able to do all that and get away with all of them having exactly 
> the same API?
> 
> IMHO working around that, passing extra objects around, sounds more stressful 
> than letting a stream on a _file_ know its filename..
> 
> If it really need it, the application certainly can retrieve the name from a 
> higher level object (a FIleReference, FileDirectory or whatever).
> 
> How does that solution allow uniformity in stream-using code?
> 
> 
> 
> 
>  
> 
> 
> 2013/11/13 Chris Muller 
> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier
>  wrote:
> > It's just a matter of selecting a strategy. I've proposed two:
> > A) create a wrapper class for legacy Stream compatibility selectors
> > B) create extensions for Legacy Stream compatibility selectors
> > My preference goes to A)
> 
> By wrappers you mean the Xtreams are the innards doing the work and
> the wrappers providing the legacy API?
> 
> This would be a great way to test Xtreams.
> 
> > The legacy support MUST be minimal (next nextPut: nextPutAll: peek upTo:
> > ...), otherwise we will import all the cruft in Xtream and would go back to
> > our starting point...
> > Once the minimal support written (a few hours should be enough), we should
> > gradually switch each every legacy Stream usage -> Xtream.
> >
> > An area which require more work is those Streams that have mixed conventions
> > (one portion is interpreted as text, another as binary).
> > In theory that's easy, we just have two streams and they both wrap on a low
> > level binary stream, but that means we have to be very cautious with buffers
> > and caches.
> >
> > Another area of work is usage of ugly selectors like name (we try to access
> > the file name from t

Re: [Pharo-dev] Spec new release :)

[Stéphane Ducasse]

I will write and send a proposal to the list. Good idea.

Stef

> Stephane I think you need to sit down and write the Guidelines for Pharo 
> Documentation, explaining the tools, the workflow, the goals, the principles 
> and most importantly where documentation can be found. Post it on pharo 
> website. This way you will save a lot of time from answering questions here . 
> So next time someone asks a relevant question you only post a link to it. 

Re: [Pharo-dev] Spec new release :)

[Stéphane Ducasse]

> It would be completely silly to have class comments in MD (no matter how cool 
> this would be) _and_ *not* be able to have Nautilus parse/render them, with 
> active links, etc…

With Athens inside the image we will use the pier parser to generate a document 
tree and render it inside the image. 
Now one step at a time. 

>> There are some PEG grammar for markdown, maybe it could be reused so PP can 
>> parse it :)
>> then one could generate Pier format out of markdown :)

What most of you do not get is that. But I do not care about Pier format. I 
care about a REAL solution that can produce a REAL document tree AND that 
***I*** can edit and maintain and enhance so that I can create books.

So I'm pragmatic we wrote the seaside book with pier so I took pier because I 
do not want to write a MD parser and building model
and reinventing the wheel. And I do not want to have to learn a new language 
just to make sure that I can write books.

Stef

Re: [Pharo-dev] Spec new release :)

[kilon alios]

Stephane I think you need to sit down and write the Guidelines for Pharo
Documentation, explaining the tools, the workflow, the goals, the
principles and most importantly where documentation can be found. Post it
on pharo website. This way you will save a lot of time from answering
questions here . So next time someone asks a relevant question you only
post a link to it.




On Wed, Nov 13, 2013 at 9:44 PM, Stéphane Ducasse  wrote:

>
> On Nov 13, 2013, at 8:22 PM, Alexandre Bergel 
> wrote:
>
> > Why not generating markdown code from pier code?
> > If the whole problem is exposure on the web. Someone has considered
> pdf2html or latex2html?
>
> I did => suicidal tendencies.
> The results looks like shit.
>
> I did not try pdf2html.
>
> Now pier is a compromise so that normal people can write chapter without
> being a latex freaks like us.
>
> Stef
>
>
> > Maybe my question is naive, I do not know.
> >
> > On some point, i have tried to generate the roassal documentation from
> the Roassal Help, but it makes the maintenance loop heavy: If I want to fix
> something in the text, I had to edit the Help in Pharo, generating the
> document, compiling into .pdf. Quite heavy it was. At the end, I only
> worked on the .tex files.
> >
> > Alexandre
> >
> >
> > On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe  wrote:
> >
> >>
> >> On 13 Nov 2013, at 19:59, Benjamin <
> benjamin.vanryseghem.ph...@gmail.com> wrote:
> >>
> >>> It was a real question, and it feels like you overreacted the answer …
> >>>
> >>> To me, markdown or pier is a new syntax to learn so I am asking …
> >>> To me, doing Pier because you do or because you said to is no really
> an argument.
> >>>
> >>> Then I am open to a real answer but I also see that markdown is
> integrated to a lot of tools (github and jekylls by examples)
> >>> and that a lot of people knows about markdown.
> >>>
> >>> This was a real question, not a troll …
> >>
> >> I like .md as well and yes, the github integration makes it compelling.
> >>
> >> But one objective argument against Markdown and in favour of Pier is
> that the former has no good parser and/or document model and and the latter
> does have both, in Pharo. That means that we can write all sorts of tools
> ourselves and get things finished, as was proven with the books.
> >>
> >> There simply isn’t any definitive, unambiguous Markdown syntax (the
> github variant is only one version).
> >>
> >>> Ben
> >>>
> >>> On 13 Nov 2013, at 19:22, Stéphane Ducasse 
> wrote:
> >>>
>  do you really think that I insist of using pier syntax because
> A- I want to lose my time
> B- this is for my ego?
> C- because I'm funny
> D- ...
> 
>  No seriously?
> 
>  If you want to get an answer read the thread that yuri raised a while
> ago.
>  Because we already discussed discussed and discussed it.
> 
>  I will not write any book in markdown. Now you can try and we see.
> 
>  Stef
> 
> > Stef, what is the advantages of writing it in Pier compared to
> markdown ?
> >
> > Ben
> >
> 
> 
> >>>
> >>
> >>
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
>
>
>

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

[Chris Muller]

On Wed, Nov 13, 2013 at 1:17 PM, Nicolas Cellier
 wrote:
> Exactly, every specialized stream has its specialized API and/or specialized
> implementation.
> File streams don't even have a name, because they need not to.
> You can browse XTFileReadStream and XTFileWriteStream, you won't find such
> thing.
> The file has a name, the stream does not need any.
> Before adding anything to a stream, ask first, why am i going to need this?

I agree with what Frank said, but not your suggestion that:

> File streams don't even have a name, because they need not to.
> If it really need it, the application certainly can retrieve the name from a 
> higher level object (a
> FIleReference, FileDirectory or whatever).

because doing that means the FileStream is no longer
fully-encapsulated.  And now for the same method to support a
non-FileStream stream, what will be passed as the new FileReference
argument?  nil?  So the code went from stream-delegation to
case-logic.

This is why organic growth happened in the original Stream hierarchy
-- because it was "needed", not random.  Not strict, yes, but not
"random" either.

One final thing to consider about selector "uniformity" is how it can
negate the ability to effectively trace code (via senders and
implementors).  Wow, how many senders of #next...?

Stream-composition is cool, though, and I understand that to be a
benefit of the stricter API.



> 2013/11/13 Frank Shearar 
>>
>> On 13 November 2013 16:48, Chris Muller  wrote:
>> > I know nothing about Xtreams but, IMO, this obsession with sterility
>> > borders on mental illness.
>> >
>> > "All sort of un-needed complexity?"  That's overstating it a bit,
>> > don't you think?
>> >
>> > So you must really feel stressed that ALL Object's, in fact, have a
>> > #name, huh?  I admit this seems to push the limits but...
>> >
>> > what's the point of having any kind of different streams at all then?
>> > It's the _differences_ between them that makes composing them useful.
>> > Compression, encryption, filtering, sockets, files, circular, etc.
>> > You think you'll be able to do all that and get away with all of them
>> > having exactly the same API?
>>
>> They don't have the same API. And they shouldn't. And that's Nicolas'
>> whole point. A Stream does not have a name (nor should it - what's the
>> name of the compressed output of an audio stream from your
>> microphone?). A FileStream can extend this API, and that's fine. But
>> keep that out of the Stream API.
>>
>> So Nicolas is arguing that _difference_ should be reflected in the
>> API. File streams have names, but generic streams do not.
>>
>> As it happens, Xtreams takes a very disciplined approach to this. Some
>> streams have positions, and so you can go back. Some can't. This is
>> reflected in the API. This is good.
>>
>> > IMHO working around that, passing extra objects around, sounds more
>> > stressful than letting a stream on a _file_ know its filename..
>>
>> Mu. Streams have no names. File streams have names.
>>
>> frank
>>
>> >> If it really need it, the application certainly can retrieve the name
>> >> from a higher level object (a FIleReference, FileDirectory or whatever).
>> >
>> > How does that solution allow uniformity in stream-using code?
>> >
>> > On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier
>> >  wrote:
>> >> Yes, a Wrapper would provide the legacy API.
>> >>
>> >> And yes, the name of a stream should better not be part of the API.
>> >> Most stream don't have a name, and adding such API adds all sort of
>> >> un-needed complexity.
>> >> It's an internal detail that can eventually help for reporting error if
>> >> accessible, but nothing more.
>> >>
>> >> If it really need it, the application certainly can retrieve the name
>> >> from a
>> >> higher level object (a FIleReference, FileDirectory or whatever).
>> >>
>> >>
>> >> 2013/11/13 Chris Muller 
>> >>>
>> >>> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier
>> >>>  wrote:
>> >>> > It's just a matter of selecting a strategy. I've proposed two:
>> >>> > A) create a wrapper class for legacy Stream compatibility selectors
>> >>> > B) create extensions for Legacy Stream compatibility selectors
>> >>> > My preference goes to A)
>> >>>
>> >>> By wrappers you mean the Xtreams are the innards doing the work and
>> >>> the wrappers providing the legacy API?
>> >>>
>> >>> This would be a great way to test Xtreams.
>> >>>
>> >>> > The legacy support MUST be minimal (next nextPut: nextPutAll: peek
>> >>> > upTo:
>> >>> > ...), otherwise we will import all the cruft in Xtream and would go
>> >>> > back
>> >>> > to
>> >>> > our starting point...
>> >>> > Once the minimal support written (a few hours should be enough), we
>> >>> > should
>> >>> > gradually switch each every legacy Stream usage -> Xtream.
>> >>> >
>> >>> > An area which require more work is those Streams that have mixed
>> >>> > conventions
>> >>> > (one portion is interpreted as text, another as binary).
>> >>> > In theory that's easy, we 

Re: [Pharo-dev] Spec new release :)

[Stéphane Ducasse]

On Nov 13, 2013, at 8:22 PM, Alexandre Bergel  wrote:

> Why not generating markdown code from pier code?
> If the whole problem is exposure on the web. Someone has considered pdf2html 
> or latex2html?

I did => suicidal tendencies.
The results looks like shit.

I did not try pdf2html.

Now pier is a compromise so that normal people can write chapter without being 
a latex freaks like us.

Stef


> Maybe my question is naive, I do not know.
> 
> On some point, i have tried to generate the roassal documentation from the 
> Roassal Help, but it makes the maintenance loop heavy: If I want to fix 
> something in the text, I had to edit the Help in Pharo, generating the 
> document, compiling into .pdf. Quite heavy it was. At the end, I only worked 
> on the .tex files.
> 
> Alexandre
> 
> 
> On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe  wrote:
> 
>> 
>> On 13 Nov 2013, at 19:59, Benjamin  
>> wrote:
>> 
>>> It was a real question, and it feels like you overreacted the answer …
>>> 
>>> To me, markdown or pier is a new syntax to learn so I am asking …
>>> To me, doing Pier because you do or because you said to is no really an 
>>> argument.
>>> 
>>> Then I am open to a real answer but I also see that markdown is integrated 
>>> to a lot of tools (github and jekylls by examples)
>>> and that a lot of people knows about markdown.
>>> 
>>> This was a real question, not a troll …
>> 
>> I like .md as well and yes, the github integration makes it compelling.
>> 
>> But one objective argument against Markdown and in favour of Pier is that 
>> the former has no good parser and/or document model and and the latter does 
>> have both, in Pharo. That means that we can write all sorts of tools 
>> ourselves and get things finished, as was proven with the books.
>> 
>> There simply isn’t any definitive, unambiguous Markdown syntax (the github 
>> variant is only one version).
>> 
>>> Ben
>>> 
>>> On 13 Nov 2013, at 19:22, Stéphane Ducasse  
>>> wrote:
>>> 
 do you really think that I insist of using pier syntax because
A- I want to lose my time
B- this is for my ego?
C- because I'm funny
D- ...
 
 No seriously?
 
 If you want to get an answer read the thread that yuri raised a while ago.
 Because we already discussed discussed and discussed it.
 
 I will not write any book in markdown. Now you can try and we see.
 
 Stef
 
> Stef, what is the advantages of writing it in Pier compared to markdown ?
> 
> Ben
> 
 
 
>>> 
>> 
>> 
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

Re: [Pharo-dev] Spec new release :)

[Stéphane Ducasse]

On Nov 13, 2013, at 8:22 PM, Alexandre Bergel  wrote:

> Why not generating markdown code from pier code?
> If the whole problem is exposure on the web. Someone has considered pdf2html 
> or latex2html? Maybe my question is naive, I do not know.

this is planned. 
Now I can count the people writing books on my right hand.

> On some point, i have tried to generate the roassal documentation from the 
> Roassal Help, but it makes the maintenance loop heavy: If I want to fix 
> something in the text, I had to edit the Help in Pharo, generating the 
> document, compiling into .pdf. Quite heavy it was. At the end, I only worked 
> on the .tex files.

I would prefer to work in tex because I go much much faster.
but I do not have a .tex parser to get a document tree.

Stef

> 
> Alexandre
> 
> 
> On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe  wrote:
> 
>> 
>> On 13 Nov 2013, at 19:59, Benjamin  
>> wrote:
>> 
>>> It was a real question, and it feels like you overreacted the answer …
>>> 
>>> To me, markdown or pier is a new syntax to learn so I am asking …
>>> To me, doing Pier because you do or because you said to is no really an 
>>> argument.
>>> 
>>> Then I am open to a real answer but I also see that markdown is integrated 
>>> to a lot of tools (github and jekylls by examples)
>>> and that a lot of people knows about markdown.
>>> 
>>> This was a real question, not a troll …
>> 
>> I like .md as well and yes, the github integration makes it compelling.
>> 
>> But one objective argument against Markdown and in favour of Pier is that 
>> the former has no good parser and/or document model and and the latter does 
>> have both, in Pharo. That means that we can write all sorts of tools 
>> ourselves and get things finished, as was proven with the books.
>> 
>> There simply isn’t any definitive, unambiguous Markdown syntax (the github 
>> variant is only one version).
>> 
>>> Ben
>>> 
>>> On 13 Nov 2013, at 19:22, Stéphane Ducasse  
>>> wrote:
>>> 
 do you really think that I insist of using pier syntax because
A- I want to lose my time
B- this is for my ego?
C- because I'm funny
D- ...
 
 No seriously?
 
 If you want to get an answer read the thread that yuri raised a while ago.
 Because we already discussed discussed and discussed it.
 
 I will not write any book in markdown. Now you can try and we see.
 
 Stef
 
> Stef, what is the advantages of writing it in Pier compared to markdown ?
> 
> Ben
> 
 
 
>>> 
>> 
>> 
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

Re: [Pharo-dev] Spec new release :)

[Stéphane Ducasse]

So read the thread that yuriy rasied last week
my sumarry
- write in pier 
publish in latex, html, markdong
- too many variation of markdown
- do not want to ask in haskell, ruby… to extend libraries
- markdown does not support references and other essential points for 
making decent books

Stef


On Nov 13, 2013, at 7:59 PM, Benjamin  
wrote:

> It was a real question, and it feels like you overreacted the answer …
> 
> To me, markdown or pier is a new syntax to learn so I am asking …
> To me, doing Pier because you do or because you said to is no really an 
> argument.
> 
> Then I am open to a real answer but I also see that markdown is integrated to 
> a lot of tools (github and jekylls by examples)
> and that a lot of people knows about markdown.
> 
> This was a real question, not a troll ...
> 
> Ben
> 
> On 13 Nov 2013, at 19:22, Stéphane Ducasse  wrote:
> 
>> do you really think that I insist of using pier syntax because
>>  A- I want to lose my time
>>  B- this is for my ego?
>>  C- because I'm funny
>>  D- ...
>> 
>> No seriously?
>> 
>> If you want to get an answer read the thread that yuri raised a while ago.
>> Because we already discussed discussed and discussed it.
>> 
>> I will not write any book in markdown. Now you can try and we see.
>> 
>> Stef
>> 
>>> Stef, what is the advantages of writing it in Pier compared to markdown ?
>>> 
>>> Ben
>>> 
>> 
>> 
> 

Re: [Pharo-dev] Spec new release :)

[Sven Van Caekenberghe]

On 13 Nov 2013, at 20:22, Alexandre Bergel  wrote:

> Why not generating markdown code from pier code?
> If the whole problem is exposure on the web. Someone has considered pdf2html 
> or latex2html? Maybe my question is naive, I do not know.

It is not silly, and yes it could be done quite easily I guess, if it even has 
not yet been done already. 

> On some point, i have tried to generate the roassal documentation from the 
> Roassal Help, but it makes the maintenance loop heavy: If I want to fix 
> something in the text, I had to edit the Help in Pharo, generating the 
> document, compiling into .pdf. Quite heavy it was. At the end, I only worked 
> on the .tex files.
> 
> Alexandre
> 
> 
> On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe  wrote:
> 
>> 
>> On 13 Nov 2013, at 19:59, Benjamin  
>> wrote:
>> 
>>> It was a real question, and it feels like you overreacted the answer …
>>> 
>>> To me, markdown or pier is a new syntax to learn so I am asking …
>>> To me, doing Pier because you do or because you said to is no really an 
>>> argument.
>>> 
>>> Then I am open to a real answer but I also see that markdown is integrated 
>>> to a lot of tools (github and jekylls by examples)
>>> and that a lot of people knows about markdown.
>>> 
>>> This was a real question, not a troll …
>> 
>> I like .md as well and yes, the github integration makes it compelling.
>> 
>> But one objective argument against Markdown and in favour of Pier is that 
>> the former has no good parser and/or document model and and the latter does 
>> have both, in Pharo. That means that we can write all sorts of tools 
>> ourselves and get things finished, as was proven with the books.
>> 
>> There simply isn’t any definitive, unambiguous Markdown syntax (the github 
>> variant is only one version).
>> 
>>> Ben
>>> 
>>> On 13 Nov 2013, at 19:22, Stéphane Ducasse  
>>> wrote:
>>> 
 do you really think that I insist of using pier syntax because
A- I want to lose my time
B- this is for my ego?
C- because I'm funny
D- ...
 
 No seriously?
 
 If you want to get an answer read the thread that yuri raised a while ago.
 Because we already discussed discussed and discussed it.
 
 I will not write any book in markdown. Now you can try and we see.
 
 Stef
 
> Stef, what is the advantages of writing it in Pier compared to markdown ?
> 
> Ben
> 
 
 
>>> 
>> 
>> 
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

Re: [Pharo-dev] Spec new release :)

[Sven Van Caekenberghe]

On 13 Nov 2013, at 20:22, Benjamin  wrote:

> On 13 Nov 2013, at 20:05, Sven Van Caekenberghe  wrote:
> 
>> 
>> On 13 Nov 2013, at 19:59, Benjamin  
>> wrote:
>> 
>>> It was a real question, and it feels like you overreacted the answer …
>>> 
>>> To me, markdown or pier is a new syntax to learn so I am asking …
>>> To me, doing Pier because you do or because you said to is no really an 
>>> argument.
>>> 
>>> Then I am open to a real answer but I also see that markdown is integrated 
>>> to a lot of tools (github and jekylls by examples)
>>> and that a lot of people knows about markdown.
>>> 
>>> This was a real question, not a troll …
>> 
>> I like .md as well and yes, the github integration makes it compelling.
>> 
>> But one objective argument against Markdown and in favour of Pier is that 
>> the former has no good parser and/or document model and and the latter does 
>> have both, in Pharo. That means that we can write all sorts of tools 
>> ourselves and get things finished, as was proven with the books.
>> 
>> There simply isn’t any definitive, unambiguous Markdown syntax (the github 
>> variant is only one version).
> 
> Ok :)
> But as an end user, do you feel the difference ?

I know, but the documentation is meant to be integrated in the Pharo ecosystem.

It would be completely silly to have class comments in MD (no matter how cool 
this would be) _and_ *not* be able to have Nautilus parse/render them, with 
active links, etc…

> There are some PEG grammar for markdown, maybe it could be reused so PP can 
> parse it :)
> then one could generate Pier format out of markdown :)

So indeed, that is what we need. [And what we already have for Pier].
But be sure to ask Camillo how his 2 attempts went before you get ambitious.
I look at the PP MD code and thought, I can do better, but after writing some 
actual code, I stopped ;-)

BTW, please point me to grammar, I never found one ! Each MD parser is one big 
hack.

> Ben
> 
>> 
>>> Ben
>>> 
>>> On 13 Nov 2013, at 19:22, Stéphane Ducasse  
>>> wrote:
>>> 
 do you really think that I insist of using pier syntax because
A- I want to lose my time
B- this is for my ego?
C- because I'm funny
D- ...
 
 No seriously?
 
 If you want to get an answer read the thread that yuri raised a while ago.
 Because we already discussed discussed and discussed it.
 
 I will not write any book in markdown. Now you can try and we see.
 
 Stef
 
> Stef, what is the advantages of writing it in Pier compared to markdown ?
> 
> Ben

Re: [Pharo-dev] PharoV20.source

[Stéphane Ducasse]

>>> Anyway, even if at the end it takes more memory than the current source 
>>> file, we should not forget that having persistant ASTs that you can freely 
>>> annotate brings far more than compression, it opens *many* doors :)
>>> The annotations on the nodes would take memory too. Well, at least for the 
>>> annotation one wants to be persistant.
>>> Even with compression, storing all the annotations one would want to have 
>>> would take too much memory. 
>>> Imagine that you want to stores additional comments and discussions 
>>> (instead of "self flag:" everywhere), statistics like code coverage, about 
>>> which class a variable had across different executions, type annotations 
>>> for many different kind of type systems (and remember its annotations, not 
>>> intrusive, no syntax change, pluggable)...
>>> That's why I want to have repositories for storing node annotations across 
>>> network.
>>> Like this we would have a compressed AST format in the image (called 
>>> Bonsai) and a mechanism for storing and sharing node annotations on 
>>> repositories (project's name: Baobab) 
>> 
>> Camille can you describe these projects in the Pharo topics on github
>> We should find a guy to work on them.
> 
> Yes but you only talk about Baobab right? Because Pablo is already working on 
> AST compression and Bonsai.

yes :)

Re: [Pharo-dev] Spec new release :)

[Alexandre Bergel]

Why not generating markdown code from pier code?
If the whole problem is exposure on the web. Someone has considered pdf2html or 
latex2html? Maybe my question is naive, I do not know.

On some point, i have tried to generate the roassal documentation from the 
Roassal Help, but it makes the maintenance loop heavy: If I want to fix 
something in the text, I had to edit the Help in Pharo, generating the 
document, compiling into .pdf. Quite heavy it was. At the end, I only worked on 
the .tex files.

Alexandre


On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe  wrote:

> 
> On 13 Nov 2013, at 19:59, Benjamin  
> wrote:
> 
>> It was a real question, and it feels like you overreacted the answer …
>> 
>> To me, markdown or pier is a new syntax to learn so I am asking …
>> To me, doing Pier because you do or because you said to is no really an 
>> argument.
>> 
>> Then I am open to a real answer but I also see that markdown is integrated 
>> to a lot of tools (github and jekylls by examples)
>> and that a lot of people knows about markdown.
>> 
>> This was a real question, not a troll …
> 
> I like .md as well and yes, the github integration makes it compelling.
> 
> But one objective argument against Markdown and in favour of Pier is that the 
> former has no good parser and/or document model and and the latter does have 
> both, in Pharo. That means that we can write all sorts of tools ourselves and 
> get things finished, as was proven with the books.
> 
> There simply isn’t any definitive, unambiguous Markdown syntax (the github 
> variant is only one version).
> 
>> Ben
>> 
>> On 13 Nov 2013, at 19:22, Stéphane Ducasse  wrote:
>> 
>>> do you really think that I insist of using pier syntax because
>>> A- I want to lose my time
>>> B- this is for my ego?
>>> C- because I'm funny
>>> D- ...
>>> 
>>> No seriously?
>>> 
>>> If you want to get an answer read the thread that yuri raised a while ago.
>>> Because we already discussed discussed and discussed it.
>>> 
>>> I will not write any book in markdown. Now you can try and we see.
>>> 
>>> Stef
>>> 
 Stef, what is the advantages of writing it in Pier compared to markdown ?
 
 Ben
 
>>> 
>>> 
>> 
> 
> 

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-dev] Spec new release :)

[Benjamin]

On 13 Nov 2013, at 20:05, Sven Van Caekenberghe  wrote:

> 
> On 13 Nov 2013, at 19:59, Benjamin  
> wrote:
> 
>> It was a real question, and it feels like you overreacted the answer …
>> 
>> To me, markdown or pier is a new syntax to learn so I am asking …
>> To me, doing Pier because you do or because you said to is no really an 
>> argument.
>> 
>> Then I am open to a real answer but I also see that markdown is integrated 
>> to a lot of tools (github and jekylls by examples)
>> and that a lot of people knows about markdown.
>> 
>> This was a real question, not a troll …
> 
> I like .md as well and yes, the github integration makes it compelling.
> 
> But one objective argument against Markdown and in favour of Pier is that the 
> former has no good parser and/or document model and and the latter does have 
> both, in Pharo. That means that we can write all sorts of tools ourselves and 
> get things finished, as was proven with the books.
> 
> There simply isn’t any definitive, unambiguous Markdown syntax (the github 
> variant is only one version).

Ok :)
But as an end user, do you feel the difference ?
There are some PEG grammar for markdown, maybe it could be reused so PP can 
parse it :)
then one could generate Pier format out of markdown :)

Ben

> 
>> Ben
>> 
>> On 13 Nov 2013, at 19:22, Stéphane Ducasse  wrote:
>> 
>>> do you really think that I insist of using pier syntax because
>>> A- I want to lose my time
>>> B- this is for my ego?
>>> C- because I'm funny
>>> D- ...
>>> 
>>> No seriously?
>>> 
>>> If you want to get an answer read the thread that yuri raised a while ago.
>>> Because we already discussed discussed and discussed it.
>>> 
>>> I will not write any book in markdown. Now you can try and we see.
>>> 
>>> Stef
>>> 
 Stef, what is the advantages of writing it in Pier compared to markdown ?
 
 Ben
 
>>> 
>>> 
>> 
> 
> 

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

[Nicolas Cellier]

Exactly, every specialized stream has its specialized API and/or
specialized implementation.
File streams don't even have a name, because they need not to.
You can browse XTFileReadStream and XTFileWriteStream, you won't find such
thing.
The file has a name, the stream does not need any.
Before adding anything to a stream, ask first, why am i going to need this?


2013/11/13 Frank Shearar 

> On 13 November 2013 16:48, Chris Muller  wrote:
> > I know nothing about Xtreams but, IMO, this obsession with sterility
> > borders on mental illness.
> >
> > "All sort of un-needed complexity?"  That's overstating it a bit,
> > don't you think?
> >
> > So you must really feel stressed that ALL Object's, in fact, have a
> > #name, huh?  I admit this seems to push the limits but...
> >
> > what's the point of having any kind of different streams at all then?
> > It's the _differences_ between them that makes composing them useful.
> > Compression, encryption, filtering, sockets, files, circular, etc.
> > You think you'll be able to do all that and get away with all of them
> > having exactly the same API?
>
> They don't have the same API. And they shouldn't. And that's Nicolas'
> whole point. A Stream does not have a name (nor should it - what's the
> name of the compressed output of an audio stream from your
> microphone?). A FileStream can extend this API, and that's fine. But
> keep that out of the Stream API.
>
> So Nicolas is arguing that _difference_ should be reflected in the
> API. File streams have names, but generic streams do not.
>
> As it happens, Xtreams takes a very disciplined approach to this. Some
> streams have positions, and so you can go back. Some can't. This is
> reflected in the API. This is good.
>
> > IMHO working around that, passing extra objects around, sounds more
> > stressful than letting a stream on a _file_ know its filename..
>
> Mu. Streams have no names. File streams have names.
>
> frank
>
> >> If it really need it, the application certainly can retrieve the name
> from a higher level object (a FIleReference, FileDirectory or whatever).
> >
> > How does that solution allow uniformity in stream-using code?
> >
> > On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier
> >  wrote:
> >> Yes, a Wrapper would provide the legacy API.
> >>
> >> And yes, the name of a stream should better not be part of the API.
> >> Most stream don't have a name, and adding such API adds all sort of
> >> un-needed complexity.
> >> It's an internal detail that can eventually help for reporting error if
> >> accessible, but nothing more.
> >>
> >> If it really need it, the application certainly can retrieve the name
> from a
> >> higher level object (a FIleReference, FileDirectory or whatever).
> >>
> >>
> >> 2013/11/13 Chris Muller 
> >>>
> >>> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier
> >>>  wrote:
> >>> > It's just a matter of selecting a strategy. I've proposed two:
> >>> > A) create a wrapper class for legacy Stream compatibility selectors
> >>> > B) create extensions for Legacy Stream compatibility selectors
> >>> > My preference goes to A)
> >>>
> >>> By wrappers you mean the Xtreams are the innards doing the work and
> >>> the wrappers providing the legacy API?
> >>>
> >>> This would be a great way to test Xtreams.
> >>>
> >>> > The legacy support MUST be minimal (next nextPut: nextPutAll: peek
> upTo:
> >>> > ...), otherwise we will import all the cruft in Xtream and would go
> back
> >>> > to
> >>> > our starting point...
> >>> > Once the minimal support written (a few hours should be enough), we
> >>> > should
> >>> > gradually switch each every legacy Stream usage -> Xtream.
> >>> >
> >>> > An area which require more work is those Streams that have mixed
> >>> > conventions
> >>> > (one portion is interpreted as text, another as binary).
> >>> > In theory that's easy, we just have two streams and they both wrap
> on a
> >>> > low
> >>> > level binary stream, but that means we have to be very cautious with
> >>> > buffers
> >>> > and caches.
> >>> >
> >>> > Another area of work is usage of ugly selectors like name (we try to
> >>> > access
> >>> > the file name from the Stream API, arghh). Those usages are bad and
> >>> > require
> >>> > a rewrite.
> >>>
> >>> Are you saying a FileStream knowing its #name or #filename is bad?
> >>>
> >>
> >
>
>

Re: [Pharo-dev] Spec new release :)

[Sven Van Caekenberghe]

On 13 Nov 2013, at 19:59, Benjamin  wrote:

> It was a real question, and it feels like you overreacted the answer …
> 
> To me, markdown or pier is a new syntax to learn so I am asking …
> To me, doing Pier because you do or because you said to is no really an 
> argument.
> 
> Then I am open to a real answer but I also see that markdown is integrated to 
> a lot of tools (github and jekylls by examples)
> and that a lot of people knows about markdown.
> 
> This was a real question, not a troll …

I like .md as well and yes, the github integration makes it compelling.

But one objective argument against Markdown and in favour of Pier is that the 
former has no good parser and/or document model and and the latter does have 
both, in Pharo. That means that we can write all sorts of tools ourselves and 
get things finished, as was proven with the books.

There simply isn’t any definitive, unambiguous Markdown syntax (the github 
variant is only one version).

> Ben
> 
> On 13 Nov 2013, at 19:22, Stéphane Ducasse  wrote:
> 
>> do you really think that I insist of using pier syntax because
>>  A- I want to lose my time
>>  B- this is for my ego?
>>  C- because I'm funny
>>  D- ...
>> 
>> No seriously?
>> 
>> If you want to get an answer read the thread that yuri raised a while ago.
>> Because we already discussed discussed and discussed it.
>> 
>> I will not write any book in markdown. Now you can try and we see.
>> 
>> Stef
>> 
>>> Stef, what is the advantages of writing it in Pier compared to markdown ?
>>> 
>>> Ben
>>> 
>> 
>> 
> 

Re: [Pharo-dev] Spec new release :)

[Benjamin]

It was a real question, and it feels like you overreacted the answer …

To me, markdown or pier is a new syntax to learn so I am asking …
To me, doing Pier because you do or because you said to is no really an 
argument.

Then I am open to a real answer but I also see that markdown is integrated to a 
lot of tools (github and jekylls by examples)
and that a lot of people knows about markdown.

This was a real question, not a troll ...

Ben

On 13 Nov 2013, at 19:22, Stéphane Ducasse  wrote:

> do you really think that I insist of using pier syntax because
>   A- I want to lose my time
>   B- this is for my ego?
>   C- because I'm funny
>   D- ...
> 
> No seriously?
> 
> If you want to get an answer read the thread that yuri raised a while ago.
> Because we already discussed discussed and discussed it.
> 
> I will not write any book in markdown. Now you can try and we see.
> 
> Stef
> 
>> Stef, what is the advantages of writing it in Pier compared to markdown ?
>> 
>> Ben
>> 
> 
> 

Re: [Pharo-dev] Instrumenting field accesses with Opal?

[Alexandre Bergel]

Thanks for discussing this issue. This is really interesting!

Alexandre


On Nov 13, 2013, at 12:02 PM, Camille Teruel  wrote:

> 
> On 13 nov. 2013, at 15:18, Andrei Chis  wrote:
> 
>> 
>> 
>> 
>> YourClass methods do: [ :method |
>>  method ast 
>>  forAllNodes: [ :node | node isVariable and: [ node isInstance ] 
>> ]
>>  putAfter: [ RFMetalink expression: 'Transcript crShow: ''iv 
>> accessed''' ];
>>  installWrapper ].
>> 
>> 
>> 
>> I tried this code but it fails in the latest version of Reflectivity :)
> 
> Neither in old ones, my mistake :)
> 
>> First "RFMetalink class(Object)>>doesNotUnderstand: #expression:"
> 
> Yes it's #fromExpression:
> 
>> then "A variable node on left side of assignment doesn''t accept metalinks"
> 
> Indeed
> For iv assignment, you should put metalinks on the assignment node.
> So it should be something like that:
> 
> YourClass methods do: [ :method |
>   method ast 
>   forAllNodes: [ :node | node isVariable and: [node isRead and: [ 
> node isInstance ] ] ]
>   putAfter: [ RFMetalink fromExpression: 'Transcript crShow: ''iv 
> read''' ];
>   forAllNodes: [ :node | node isAssignment and: [ node variable 
> isInstance ] ]
>   putAfter: [ RFMetalink fromExpression: 'Transcript crShow: ''iv 
> written''' ];
>   installWrapper ]
>   
> 
>>  
>>> 
>>> Alexandre
>>> -- 
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

[Frank Shearar]

On 13 November 2013 16:48, Chris Muller  wrote:
> I know nothing about Xtreams but, IMO, this obsession with sterility
> borders on mental illness.
>
> "All sort of un-needed complexity?"  That's overstating it a bit,
> don't you think?
>
> So you must really feel stressed that ALL Object's, in fact, have a
> #name, huh?  I admit this seems to push the limits but...
>
> what's the point of having any kind of different streams at all then?
> It's the _differences_ between them that makes composing them useful.
> Compression, encryption, filtering, sockets, files, circular, etc.
> You think you'll be able to do all that and get away with all of them
> having exactly the same API?

They don't have the same API. And they shouldn't. And that's Nicolas'
whole point. A Stream does not have a name (nor should it - what's the
name of the compressed output of an audio stream from your
microphone?). A FileStream can extend this API, and that's fine. But
keep that out of the Stream API.

So Nicolas is arguing that _difference_ should be reflected in the
API. File streams have names, but generic streams do not.

As it happens, Xtreams takes a very disciplined approach to this. Some
streams have positions, and so you can go back. Some can't. This is
reflected in the API. This is good.

> IMHO working around that, passing extra objects around, sounds more
> stressful than letting a stream on a _file_ know its filename..

Mu. Streams have no names. File streams have names.

frank

>> If it really need it, the application certainly can retrieve the name from a 
>> higher level object (a FIleReference, FileDirectory or whatever).
>
> How does that solution allow uniformity in stream-using code?
>
> On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier
>  wrote:
>> Yes, a Wrapper would provide the legacy API.
>>
>> And yes, the name of a stream should better not be part of the API.
>> Most stream don't have a name, and adding such API adds all sort of
>> un-needed complexity.
>> It's an internal detail that can eventually help for reporting error if
>> accessible, but nothing more.
>>
>> If it really need it, the application certainly can retrieve the name from a
>> higher level object (a FIleReference, FileDirectory or whatever).
>>
>>
>> 2013/11/13 Chris Muller 
>>>
>>> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier
>>>  wrote:
>>> > It's just a matter of selecting a strategy. I've proposed two:
>>> > A) create a wrapper class for legacy Stream compatibility selectors
>>> > B) create extensions for Legacy Stream compatibility selectors
>>> > My preference goes to A)
>>>
>>> By wrappers you mean the Xtreams are the innards doing the work and
>>> the wrappers providing the legacy API?
>>>
>>> This would be a great way to test Xtreams.
>>>
>>> > The legacy support MUST be minimal (next nextPut: nextPutAll: peek upTo:
>>> > ...), otherwise we will import all the cruft in Xtream and would go back
>>> > to
>>> > our starting point...
>>> > Once the minimal support written (a few hours should be enough), we
>>> > should
>>> > gradually switch each every legacy Stream usage -> Xtream.
>>> >
>>> > An area which require more work is those Streams that have mixed
>>> > conventions
>>> > (one portion is interpreted as text, another as binary).
>>> > In theory that's easy, we just have two streams and they both wrap on a
>>> > low
>>> > level binary stream, but that means we have to be very cautious with
>>> > buffers
>>> > and caches.
>>> >
>>> > Another area of work is usage of ugly selectors like name (we try to
>>> > access
>>> > the file name from the Stream API, arghh). Those usages are bad and
>>> > require
>>> > a rewrite.
>>>
>>> Are you saying a FileStream knowing its #name or #filename is bad?
>>>
>>
>

Re: [Pharo-dev] Spec new release :)

[Stéphane Ducasse]

What is the point of this folder?
Do you expect us to write documentation there?
Why do you systematically are again pier?  especially when I wrote successfully 
the seaside book with it
and so far the only book I saw using markdown are not book?

May be I should go back to write in plain latex and like that everybody will be 
happy.
Or I should even do not write any book. Because when I see the amount of energy 
it takes and 
after people kill my fun with fucking syntactic issue because I do not use 
markdown.

Stef

> I added https://github.com/pharo-project/pharo-documentation 
> 
> On 2013-11-13, at 02:47, Stéphane Ducasse  wrote:
> 
>> Ben it would be good to do it pier format so that we get html and pdf
>> and also to avoid to have documentation spread all over.
>> 
>> Stef
>> 
>> On Nov 12, 2013, at 11:42 PM, Benjamin 
>>  wrote:
>> 
>>> Yes it is planned :)
>>> 
>>> The idea is to have it ready for the release of Pharo 3.0 (at last).
>>> There is a git repo I just opened[1] where the doc will be :)
>>> 
>>> Every body is free to fork it and to pull-request me :)
>>> 
>>> Ben
>>> [1]https://github.com/BenjaminVanRyseghem/Spec_Documentation
>>> 
>>> On 12 Nov 2013, at 23:09, kilon alios  wrote:
>>> 
 Is there any new documentation planned ? 
 
 
 On Tue, Nov 12, 2013 at 11:42 PM, Benjamin 
  wrote:
 Confirmed and fixed :P
 https://pharo.fogbugz.com/default.asp?12153
 
 
 Ben
 
 On 12 Nov 2013, at 17:08, Martin Dias  wrote:
 
> (Checked in Pharo 30567)
> 
> On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias  wrote:
>> Thanks Ben. It's neat to have Spec models for tree columns. It was
>> strange to instantiate MorphTreeColumnMorph directly from my Spec
>> model.
>> 
>> I found an issue in TreeModel: Only one level of children is shown.
>> Reproduce with:
>> 
>> TreeModel new
>> roots: (1 to: 5);
>> childrenBlock: [ :item | 1+item to: 5+item ];
>> openWithSpec
>> 
>> Should I report?
>> 
>> Martín
>> 
>> On Tue, Nov 12, 2013 at 2:59 PM, Benjamin
>>  wrote:
>>> It’s this one: https://pharo.fogbugz.com/default.asp?12135
>>> 
>>> Ben
>>> 
>>> On 12 Nov 2013, at 14:49, Martin Dias  wrote:
>>> 
>>> I forgot to specify: in latest Pharo (30565)
>>> 
>>> On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias  
>>> wrote:
>>> 
>>> I think there is some issue with TreeColumnModel. For example:
>>> 
>>> TreeModel exampleWithCustomColumnsAndNodes
>>> 
>>> Raises "ByteSymbol(Object)>>doesNotUnderstand: #adapt:"
>>> 
>>> Should I report in fogbugz?
>>> 
>>> thanks,
>>> Martín
>>> 
>>> On Tue, Nov 12, 2013 at 2:21 PM, Stéphane Ducasse
>>>  wrote:
>>> 
>>> Yes this is what I did for the change sorter. I do not like this DSL 
>>> like
>>> way of passing block over block over block
>>> over blocks.
>>> 
>>> I love blocks but methods are named blocks and I prefer them.
>>> 
>>> Stef
>>> 
>>> biut that method can be written:
>>> 
>>> aMenu addGroup: (MenuGroupModel new
>>> addItem: (MenuItemModel new
>>> name: 'Browse Full';
>>> action: [ self browseSelectedObject ];
>>> shortcut: $b command mac | $b alt win | $b alt unix);
>>> addItem: (MenuItem new
>>> name: 'Browse Class';
>>> action: [ self browseSelectedObjectClass ])).
>>> 
>>> and you do not have to declare variables for that (and is a lot better 
>>> than
>>> using a block, IMO).
>>> 
>>> 
>>> 
>>> On Nov 12, 2013, at 9:36 AM, Benjamin 
>>> 
>>> wrote:
>>> 
>>> One can just use an object too.
>>> 
>>> It’s just that otherwise, it pollutes a bit the method with tons of inst
>>> vars
>>> (and then you forget to use them :P)
>>> 
>>> Ben
>>> 
>>> On 12 Nov 2013, at 13:05, Esteban Lorenzano  wrote:
>>> 
>>> 
>>> On Nov 12, 2013, at 4:22 AM, Benjamin 
>>> 
>>> wrote:
>>> 
>>> It is not necessary better, but it saves you from having hundreds of 
>>> temp
>>> vars :)
>>> 
>>> Ben
>>> 
>>> On 12 Nov 2013, at 01:49, Stéphane Ducasse 
>>> wrote:
>>> 
>>> 
>>> Example:
>>> aMenu addGroup: [ :aGroup |
>>> aGroup addItem: [ :anItem |
>>> anItem name: 'Browse Full';
>>> action: [ self browseSelectedObject ];
>>> shortcut: $b command mac | $b alt win | $b alt unix  ].
>>> aGroup addItem: [ :anItem |
>>> anItem name: 'Browse Class';
>>> action: [ self browseSelectedObjectClass ] ] ].
>>> 
>>> 
>>> I do not see the value of passing block to add element to groups
>>> why not the normal way i.e. passing an object. I do not get why 
>>> executing
>>> a block with an object is better?
>>> 
>>> 
>>> he, I thought the same :)
>>> 
>>> 
>>> Stef
>>> 
>>> 
>>> 
>>

Re: [Pharo-dev] Spec new release :)

[Stéphane Ducasse]

do you really think that I insist of using pier syntax because
A- I want to lose my time
B- this is for my ego?
C- because I'm funny
D- ...

No seriously?

If you want to get an answer read the thread that yuri raised a while ago.
Because we already discussed discussed and discussed it.

I will not write any book in markdown. Now you can try and we see.

Stef

> Stef, what is the advantages of writing it in Pier compared to markdown ?
> 
> Ben
> 

Re: [Pharo-dev] Spec new release :)

[Stéphane Ducasse]

do it in whatever you want but do not ask me to edit it nor to put it in our 
book.

Stef

On Nov 13, 2013, at 1:19 PM, Benjamin  
wrote:

> Stef, what is the advantages of writing it in Pier compared to markdown ?
> 
> Ben
> 

Re: [Pharo-dev] Spec new release :)

[Stéphane Ducasse]

I give up.

Stef

On Nov 13, 2013, at 1:19 PM, Benjamin  
wrote:

> Stef, what is the advantages of writing it in Pier compared to markdown ?
> 
> Ben
> 

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

[Nicolas Cellier]

Just forgot to add this reductio ad absurdum:
I suggest Object ^'John Doe', this is a relatively current name, so it
shouldn't hurt.


2013/11/13 Nicolas Cellier 

>
> -- Forwarded message --
> From: Nicolas Cellier 
> Date: 2013/11/13
> Subject: Re: [Pharo-dev] In-memory FileSystem write streams not being
> polymorphic
>
> The long answer is simple: the more responsibility you put in Stream, the
> more complexity you get.
> The first complexity that I'm speaking of is non-uniformity and random
> implementation (or un-implementation) of a set of features.
> I mean some streams in the huge hierarchy implement only half of the
> contract, but hey, what was the contract exactly?
> Ah, yes, there were no contract, just hacks left here and there randomly
> and concurrently in a big hierarchy.
> I add a new subclass, but don't implement all the features, there are too
> many of them, and I don't know them all..
> I add a new feature, but don't implement it in all the classes, there are
> too many of them, and I don't know them all.
> This procedure invariably ends up with a blob of un-maintanable code, were
> two stream would not even agree on upToEnd behavior - I think you remember
> it :)
>
> If the goal is to replicate all the accumulated responsibilities of Squeak
> Streams, but with a clarified contract, I think this is a dead end: too
> much cruft to support, too many features, too many undefined or not well
> defined behaviors to be clarified.
>
> Xtreams takes the opposite path: concentrate on constructing a common,
> simple and uniform API, concerning streams, just basic stream methods.
> Some specialized streams then implement some specialized behavior, and you
> can compose them (by wrapping) when you need the specific API.
> This way, you ain't got to implement/maintain feature A into a few dozen
> of classes.
> And your brand new SpecialFeatureBStream only has to implement a few well
> known behaviours and your Special Feature B.
>
> The short answer is even more simple : a stream does not have a name, like
> a collection does not have a name, because we ain't gonna need it.
> If we really need a name, then we'll create a XTNamedReadStream and a
> XTNamedWriteStream responding to #name, but I doubt we'll do.
>
>
> 2013/11/13 Chris Muller 
>
>> On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier <
>> nicolas.cellier.aka.n...@gmail.com> wrote:
>>
>>> Yes, a Wrapper would provide the legacy API.
>>>
>>> And yes, the name of a stream should better not be part of the API.
>>> Most stream don't have a name, and adding such API adds all sort of
>>> un-needed complexity.
>>> It's an internal detail that can eventually help for reporting error if
>>> accessible, but nothing more.
>>>
>>>
>> I know nothing about Xtreams but, IMO, this obsession with sterility
>> borders on mental illness.
>>
>> "All sort of un-needed complexity?"  That's overstating it a bit, don't
>> you think?
>>
>> So you must really feel stressed that ALL Object's, in fact, have a
>> #name, huh?  I admit this seems to push the limits but...
>>
>> what's the point of having any kind of different streams at all then?
>>  It's the _differences_ between them that makes composing them useful.
>>  Compression, encryption, filtering, sockets, files, circular, etc.  You
>> think you'll be able to do all that and get away with all of them having
>> exactly the same API?
>>
>> IMHO working around that, passing extra objects around, sounds more
>> stressful than letting a stream on a _file_ know its filename..
>>
>> If it really need it, the application certainly can retrieve the name
>>> from a higher level object (a FIleReference, FileDirectory or whatever).
>>>
>>
>> How does that solution allow uniformity in stream-using code?
>>
>>
>>
>>
>>
>>
>>>
>>>
>>> 2013/11/13 Chris Muller 
>>>
 On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier
  wrote:
 > It's just a matter of selecting a strategy. I've proposed two:
 > A) create a wrapper class for legacy Stream compatibility selectors
 > B) create extensions for Legacy Stream compatibility selectors
 > My preference goes to A)

 By wrappers you mean the Xtreams are the innards doing the work and
 the wrappers providing the legacy API?

 This would be a great way to test Xtreams.

 > The legacy support MUST be minimal (next nextPut: nextPutAll: peek
 upTo:
 > ...), otherwise we will import all the cruft in Xtream and would go
 back to
 > our starting point...
 > Once the minimal support written (a few hours should be enough), we
 should
 > gradually switch each every legacy Stream usage -> Xtream.
 >
 > An area which require more work is those Streams that have mixed
 conventions
 > (one portion is interpreted as text, another as binary).
 > In theory that's easy, we just have two streams and they both wrap on
 a low
 > level binary stream, but that means we have to be very cautious wi

[Pharo-dev] Fwd: In-memory FileSystem write streams not being polymorphic

[Nicolas Cellier]

-- Forwarded message --
From: Nicolas Cellier 
Date: 2013/11/13
Subject: Re: [Pharo-dev] In-memory FileSystem write streams not being
polymorphic

The long answer is simple: the more responsibility you put in Stream, the
more complexity you get.
The first complexity that I'm speaking of is non-uniformity and random
implementation (or un-implementation) of a set of features.
I mean some streams in the huge hierarchy implement only half of the
contract, but hey, what was the contract exactly?
Ah, yes, there were no contract, just hacks left here and there randomly
and concurrently in a big hierarchy.
I add a new subclass, but don't implement all the features, there are too
many of them, and I don't know them all..
I add a new feature, but don't implement it in all the classes, there are
too many of them, and I don't know them all.
This procedure invariably ends up with a blob of un-maintanable code, were
two stream would not even agree on upToEnd behavior - I think you remember
it :)

If the goal is to replicate all the accumulated responsibilities of Squeak
Streams, but with a clarified contract, I think this is a dead end: too
much cruft to support, too many features, too many undefined or not well
defined behaviors to be clarified.

Xtreams takes the opposite path: concentrate on constructing a common,
simple and uniform API, concerning streams, just basic stream methods.
Some specialized streams then implement some specialized behavior, and you
can compose them (by wrapping) when you need the specific API.
This way, you ain't got to implement/maintain feature A into a few dozen of
classes.
And your brand new SpecialFeatureBStream only has to implement a few well
known behaviours and your Special Feature B.

The short answer is even more simple : a stream does not have a name, like
a collection does not have a name, because we ain't gonna need it.
If we really need a name, then we'll create a XTNamedReadStream and a
XTNamedWriteStream responding to #name, but I doubt we'll do.


2013/11/13 Chris Muller 

> On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com> wrote:
>
>> Yes, a Wrapper would provide the legacy API.
>>
>> And yes, the name of a stream should better not be part of the API.
>> Most stream don't have a name, and adding such API adds all sort of
>> un-needed complexity.
>> It's an internal detail that can eventually help for reporting error if
>> accessible, but nothing more.
>>
>>
> I know nothing about Xtreams but, IMO, this obsession with sterility
> borders on mental illness.
>
> "All sort of un-needed complexity?"  That's overstating it a bit, don't
> you think?
>
> So you must really feel stressed that ALL Object's, in fact, have a #name,
> huh?  I admit this seems to push the limits but...
>
> what's the point of having any kind of different streams at all then?
>  It's the _differences_ between them that makes composing them useful.
>  Compression, encryption, filtering, sockets, files, circular, etc.  You
> think you'll be able to do all that and get away with all of them having
> exactly the same API?
>
> IMHO working around that, passing extra objects around, sounds more
> stressful than letting a stream on a _file_ know its filename..
>
> If it really need it, the application certainly can retrieve the name from
>> a higher level object (a FIleReference, FileDirectory or whatever).
>>
>
> How does that solution allow uniformity in stream-using code?
>
>
>
>
>
>
>>
>>
>> 2013/11/13 Chris Muller 
>>
>>> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier
>>>  wrote:
>>> > It's just a matter of selecting a strategy. I've proposed two:
>>> > A) create a wrapper class for legacy Stream compatibility selectors
>>> > B) create extensions for Legacy Stream compatibility selectors
>>> > My preference goes to A)
>>>
>>> By wrappers you mean the Xtreams are the innards doing the work and
>>> the wrappers providing the legacy API?
>>>
>>> This would be a great way to test Xtreams.
>>>
>>> > The legacy support MUST be minimal (next nextPut: nextPutAll: peek
>>> upTo:
>>> > ...), otherwise we will import all the cruft in Xtream and would go
>>> back to
>>> > our starting point...
>>> > Once the minimal support written (a few hours should be enough), we
>>> should
>>> > gradually switch each every legacy Stream usage -> Xtream.
>>> >
>>> > An area which require more work is those Streams that have mixed
>>> conventions
>>> > (one portion is interpreted as text, another as binary).
>>> > In theory that's easy, we just have two streams and they both wrap on
>>> a low
>>> > level binary stream, but that means we have to be very cautious with
>>> buffers
>>> > and caches.
>>> >
>>> > Another area of work is usage of ugly selectors like name (we try to
>>> access
>>> > the file name from the Stream API, arghh). Those usages are bad and
>>> require
>>> > a rewrite.
>>>
>>> Are you saying a FileStream knowing its #name or #filename is bad?
>>>
>>>
>>
>

Re: [Pharo-dev] NativeBoost: Documentation Suggestion and Question

[Sean P. DeNigris]

Igor Stasenko wrote
> PaError Pa_OpenDefaultStream(NBExternalAddress * stream ... )
> then your call site will look like following:
> streamHandle := NBExternalAddress new.

Okay, one step closer. I somewhat randomly guessed to use NBExternalAddress,
but didn't have the correct thing in the signature...


Igor Stasenko wrote
> But hold on, next thing you will stuck with is callback ... hehe :)
> ...
> for that, again you can just change the function signature and...
> put nil. (yes, nil literal)

So you're saying the signature would become:
nbCall: #(PaError Pa_OpenDefaultStream(NBExternalAddress * stream,
...
ulong   framesPerBuffer,
nil,
void *  userData))

I made the changes as I understood them, but I'm getting a "generic failure"
when I call Pa_OpenDefaultStream.

I uploaded the latest changes to the repo...



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/NativeBoost-Documentation-Suggestion-and-Question-tp4720805p4721810.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

[Chris Muller]

I know nothing about Xtreams but, IMO, this obsession with sterility
borders on mental illness.

"All sort of un-needed complexity?"  That's overstating it a bit,
don't you think?

So you must really feel stressed that ALL Object's, in fact, have a
#name, huh?  I admit this seems to push the limits but...

what's the point of having any kind of different streams at all then?
It's the _differences_ between them that makes composing them useful.
Compression, encryption, filtering, sockets, files, circular, etc.
You think you'll be able to do all that and get away with all of them
having exactly the same API?

IMHO working around that, passing extra objects around, sounds more
stressful than letting a stream on a _file_ know its filename..

> If it really need it, the application certainly can retrieve the name from a 
> higher level object (a FIleReference, FileDirectory or whatever).

How does that solution allow uniformity in stream-using code?

On Wed, Nov 13, 2013 at 9:58 AM, Nicolas Cellier
 wrote:
> Yes, a Wrapper would provide the legacy API.
>
> And yes, the name of a stream should better not be part of the API.
> Most stream don't have a name, and adding such API adds all sort of
> un-needed complexity.
> It's an internal detail that can eventually help for reporting error if
> accessible, but nothing more.
>
> If it really need it, the application certainly can retrieve the name from a
> higher level object (a FIleReference, FileDirectory or whatever).
>
>
> 2013/11/13 Chris Muller 
>>
>> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier
>>  wrote:
>> > It's just a matter of selecting a strategy. I've proposed two:
>> > A) create a wrapper class for legacy Stream compatibility selectors
>> > B) create extensions for Legacy Stream compatibility selectors
>> > My preference goes to A)
>>
>> By wrappers you mean the Xtreams are the innards doing the work and
>> the wrappers providing the legacy API?
>>
>> This would be a great way to test Xtreams.
>>
>> > The legacy support MUST be minimal (next nextPut: nextPutAll: peek upTo:
>> > ...), otherwise we will import all the cruft in Xtream and would go back
>> > to
>> > our starting point...
>> > Once the minimal support written (a few hours should be enough), we
>> > should
>> > gradually switch each every legacy Stream usage -> Xtream.
>> >
>> > An area which require more work is those Streams that have mixed
>> > conventions
>> > (one portion is interpreted as text, another as binary).
>> > In theory that's easy, we just have two streams and they both wrap on a
>> > low
>> > level binary stream, but that means we have to be very cautious with
>> > buffers
>> > and caches.
>> >
>> > Another area of work is usage of ugly selectors like name (we try to
>> > access
>> > the file name from the Stream API, arghh). Those usages are bad and
>> > require
>> > a rewrite.
>>
>> Are you saying a FileStream knowing its #name or #filename is bad?
>>
>

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

[Nicolas Cellier]

Yes, a Wrapper would provide the legacy API.

And yes, the name of a stream should better not be part of the API.
Most stream don't have a name, and adding such API adds all sort of
un-needed complexity.
It's an internal detail that can eventually help for reporting error if
accessible, but nothing more.

If it really need it, the application certainly can retrieve the name from
a higher level object (a FIleReference, FileDirectory or whatever).


2013/11/13 Chris Muller 

> On Tue, Nov 12, 2013 at 7:31 AM, Nicolas Cellier
>  wrote:
> > It's just a matter of selecting a strategy. I've proposed two:
> > A) create a wrapper class for legacy Stream compatibility selectors
> > B) create extensions for Legacy Stream compatibility selectors
> > My preference goes to A)
>
> By wrappers you mean the Xtreams are the innards doing the work and
> the wrappers providing the legacy API?
>
> This would be a great way to test Xtreams.
>
> > The legacy support MUST be minimal (next nextPut: nextPutAll: peek upTo:
> > ...), otherwise we will import all the cruft in Xtream and would go back
> to
> > our starting point...
> > Once the minimal support written (a few hours should be enough), we
> should
> > gradually switch each every legacy Stream usage -> Xtream.
> >
> > An area which require more work is those Streams that have mixed
> conventions
> > (one portion is interpreted as text, another as binary).
> > In theory that's easy, we just have two streams and they both wrap on a
> low
> > level binary stream, but that means we have to be very cautious with
> buffers
> > and caches.
> >
> > Another area of work is usage of ugly selectors like name (we try to
> access
> > the file name from the Stream API, arghh). Those usages are bad and
> require
> > a rewrite.
>
> Are you saying a FileStream knowing its #name or #filename is bad?
>
>

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 80426c: 30570

[GitHub]

  Branch: refs/heads/3.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 80426c3280e89d9e72ab38aac1f75f5353560448
  
https://github.com/pharo-project/pharo-core/commit/80426c3280e89d9e72ab38aac1f75f5353560448
  Author: Jenkins Build Server 
  Date:   2013-11-13 (Wed, 13 Nov 2013)

  Changed paths:
A 
Keymapping-Core.package/KMCategory.class/instance/associating/removeKeymapEntry_.st
A 
Keymapping-Core.package/KMCategory.class/instance/binding/keymapForShortcut_.st
A 
Keymapping-Core.package/KMDispatcher.class/instance/building/keymapForShortcut_.st
A 
Keymapping-Core.package/KMDispatcher.class/instance/building/removeKeyCombination_.st
M Keymapping-Core.package/KMStorage.class/definition.st
M Keymapping-Core.package/KMStorage.class/instance/accessing/add_.st
A 
Keymapping-Core.package/KMStorage.class/instance/accessing/keymapForShortcut_.st
M Keymapping-Core.package/KMStorage.class/instance/accessing/keymaps.st
A Keymapping-Core.package/KMStorage.class/instance/accessing/remove_.st
M 
Keymapping-Core.package/KMStorage.class/instance/initialization/initialize.st
A Keymapping-Core.package/extension/Morph/instance/removeKeyCombination_.st
A ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script226.st
A ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
updates/update30570.st
M 
ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st

  Log Message:
  ---
  30570
12149 Add support for removing a binding
https://pharo.fogbugz.com/f/cases/12149

http://files.pharo.org/image/30/30570.zip

[Pharo-dev] [regression reporter]regression occurred

[no-reply]

https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/Run=run%201,VM=vm,label=linux/278/

1 regressions found.
  FileSystem.Tests.Disk.FileHandleTest.testTruncate

[Pharo-dev] Jenkins build became unstable: Pharo-2.0-Tests » run 1,vm,linux #278

[no-reply]

See 

Re: [Pharo-dev] Instrumenting field accesses with Opal?

[Camille Teruel]

On 13 nov. 2013, at 15:18, Andrei Chis  wrote:

> 
> 
> 
> YourClass methods do: [ :method |
>   method ast 
>   forAllNodes: [ :node | node isVariable and: [ node isInstance ] 
> ]
>   putAfter: [ RFMetalink expression: 'Transcript crShow: ''iv 
> accessed''' ];
>   installWrapper ].
> 
> 
> 
> I tried this code but it fails in the latest version of Reflectivity :)

Neither in old ones, my mistake :)

> First "RFMetalink class(Object)>>doesNotUnderstand: #expression:"

Yes it's #fromExpression:

> then "A variable node on left side of assignment doesn''t accept metalinks"

Indeed
For iv assignment, you should put metalinks on the assignment node.
So it should be something like that:

YourClass methods do: [ :method |
method ast 
forAllNodes: [ :node | node isVariable and: [node isRead and: [ 
node isInstance ] ] ]
putAfter: [ RFMetalink fromExpression: 'Transcript crShow: ''iv 
read''' ];
forAllNodes: [ :node | node isAssignment and: [ node variable 
isInstance ] ]
putAfter: [ RFMetalink fromExpression: 'Transcript crShow: ''iv 
written''' ];
installWrapper ]


>  
>>  
>> Alexandre
>> -- 
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> 
>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] Instrumenting field accesses with Opal?

[Andrei Chis]

> YourClass methods do: [ :method |
> method ast
> forAllNodes: [ :node | node isVariable and: [ node isInstance ] ]
>  putAfter: [ RFMetalink expression: 'Transcript crShow: ''iv accessed'''
> ];
> installWrapper ].
>
>

I tried this code but it fails in the latest version of Reflectivity :)
First "RFMetalink class(Object)>>doesNotUnderstand: #expression:"
then "A variable node on left side of assignment doesn''t accept metalinks"



>  Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>

Re: [Pharo-dev] Peek

[Sven Van Caekenberghe]

On 06 Nov 2013, at 13:56, Sven Van Caekenberghe  wrote:

> 
> On 06 Nov 2013, at 13:20, Henrik Johansen  
> wrote:
> 
>> 
>> On 04 Nov 2013, at 5:12 , Sven Van Caekenberghe  wrote:
>> 
>>> 
>>> Well, I just realised that ZnCharacterReadStream and ZnCharacterWriteStream 
>>> did not yet make use of the optimisations that I did for 
>>> ZnCharacterEncoding some time ago. More specifically, they were not yet 
>>> using #next:putAll:startingAt:toStream: and 
>>> #readInto:startingAt:count:fromStream: which are overwritten for 
>>> ZnUTF8Encoder with (super hacked) versions that assume most of the input 
>>> will be ASCII (a reasonable assumption).
>>> 
>>> I am still chasing a bug, but right now:
>>> 
>>> [ (ZnCharacterReadStream on: ('timezones.json' asFileReference readStream 
>>> binary))
>>> next: 65536; close ] bench. 
>>> 
>>> "135 per second.” BEFORE
>>> "3,310 per second.” AFTER
>>> 
>>> But of course the input file is ASCII, so YMMV.
>>> 
>>> I’ll let you know when I commit this code.
>>> 
>>> Sven
>> 
>> Yeah… sooo, I loaded the updated version, great improvement for streams on 
>> Latin1 content :D
>> 
>> Maybe it’s just me, but I tested with actual wide source as well (it was as 
>> slow as you’d expect), and I think you need a notQuiteSoOptimizedReadInto* 
>> which uses the normal Byte -> Wide become: conversion machinery.
>> Writing a ZnByteStringBecameWideString handler for every next: (and cousins) 
>> call where source may be non-latin1 is a real chore/nasty surprise for those 
>> used to dealing with legacy streams/converters... 
>> You can sort of kinda make up for the performance hit (at least on these 
>> sizes) with a faster replace:from:to:with:startingAt: in use after the fact, 
>> by using basicAt:put: to the string, thus avoiding converting the 
>> replacement value to character. 
>> 
>> Cheers,
>> Henry
>> 
>> PS: Why is ZnByteStringBecameWideString a notification and not a resumable 
>> exception? I would assume those who run into it without a handler would 
>> rather have an actual error, than a result where their string has been read 
>> up to the first wide char…
> 
> Henrik, thanks again for the feedback, it is really useful.
> 
> You are right, the ZnByteStringBecameWideString hack was introduced 
> specifically to avoid the become, because benchmarking showed that it took 
> too long. The original user is ZnStringEntity>>#readFrom: 
> 
> Now, if you know up front that your string will be wide anyway, then there is 
> #decodeBytesIntoWideString:
> 
> Yes, ZnByteStringBecameWideString should probably be a resumable exception, 
> as not handling it properly will lead to errors.
> 
> I will have to think and reconsider the generality/specificity of the 
> optimisation hack in ZnUTF8Encoder. I got some ideas, but it will take some 
> time.
> 
> At least the code works now, time to process the constructive criticism.

===
Name: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.28
Author: SvenVanCaekenberghe
Time: 13 November 2013, 3:04:00.925461 pm
UUID: f104e1ee-7fe5-4a23-a650-197dd9462783
Ancestors: Zinc-Character-Encoding-Core-SvenVanCaekenberghe.27

ZnByteStringBecameWideString is now a resumable Error instead of a Notification 
(as suggested by henrik sperre johansen);
Added ZnByteStringBecameWideString>>#becomeForward convenience method
Fixed ZnCharacterReadStream>>#readInto:startingAt:count: to do the actual 
becomeForward when needed so that clients are not affected
===
Name: Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.15
Author: SvenVanCaekenberghe
Time: 13 November 2013, 3:05:18.26391 pm
UUID: 8c41ee29-9906-4626-a9da-cb576980cd4c
Ancestors: Zinc-Character-Encoding-Tests-SvenVanCaekenberghe.14

Added a unit test to make sure 
ZnCharacterReadStream>>#readInto:startingAt:count: does an actual becomeForward 
when needed
===

At least the situation is correct now.

Sven

Re: [Pharo-dev] Instrumenting field accesses with Opal?

[Camille Teruel]

On 13 nov. 2013, at 14:51, Marcus Denker  wrote:

> 
> On 13 Nov 2013, at 14:44, Camillo Bruni  wrote:
> 
>> 
>> On 2013-11-13, at 14:42, Camille Teruel  wrote:
>>> On 13 nov. 2013, at 14:21, Alexandre Bergel  wrote:
>>> 
 Hi!
 
 Is there a way to get notified when fields are accessed?
 That would be awesome
>>> 
>>> You can use the current reflectivity prototype. It's on RMoD CI: 
>>> https://ci.inria.fr/rmod/job/Reflectivity/
>>> It should look like something like that:
>>> 
>>> YourClass methods do: [ :method |
>>> method ast 
>>> forAllNodes: [ :node | node isVariable and: [ node isInstance ] 
>>> ]
>>> putAfter: [ RFMetalink expression: 'Transcript crShow: ''iv 
>>> accessed''' ];
>>> installWrapper ].
>> 
>> In the end we should be able to just use the Slot MOP ;)
> 
> or put a link on the slot object instead of all the AST nodes of accesses.

Yes it will be more concise and high-level (even if behind the scenes, the same 
thing happens)
It will be for Pharo 4.0, an awesome release for sure :)

> 
>   Marcus

Re: [Pharo-dev] PharoV20.source

[Camille Teruel]

On 13 nov. 2013, at 14:42, Igor Stasenko  wrote:

> 2 cents.
> just want to make a note, it is important to preserve original text
> (yes i am talking about formatting, spacing, tabs etc)..
> because without it i can easily imagine you can raise compression ration to 
> the skies..
> but as to me the original text is important part of game.

Don't worry, formatting information will be stored in Bonsai (as extrinsic 
information of the flyweight like node properties, not in the flyweights 
themselves).
You won't notice that there is no original text, source will be reconstructed 
on demand.

> 
> 
> 
> On 13 November 2013 12:58, Marcus Denker  wrote:
> 
> On 13 Nov 2013, at 12:02, p...@highoctane.be wrote:
> 
> > Very exciting developments.
> >
> > How would you keep "sources" and "changes" segregated BTW? (if we can still 
> > call them like that).
> >
> changes are modelled by Martin’s system (EPICEA).
> 
> Marcus
> 
> 
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko.

Re: [Pharo-dev] Instrumenting field accesses with Opal?

[Marcus Denker]

On 13 Nov 2013, at 14:44, Camillo Bruni  wrote:

> 
> On 2013-11-13, at 14:42, Camille Teruel  wrote:
>> On 13 nov. 2013, at 14:21, Alexandre Bergel  wrote:
>> 
>>> Hi!
>>> 
>>> Is there a way to get notified when fields are accessed?
>>> That would be awesome
>> 
>> You can use the current reflectivity prototype. It's on RMoD CI: 
>> https://ci.inria.fr/rmod/job/Reflectivity/
>> It should look like something like that:
>> 
>> YourClass methods do: [ :method |
>>  method ast 
>>  forAllNodes: [ :node | node isVariable and: [ node isInstance ] 
>> ]
>>  putAfter: [ RFMetalink expression: 'Transcript crShow: ''iv 
>> accessed''' ];
>>  installWrapper ].
> 
> In the end we should be able to just use the Slot MOP ;)

or put a link on the slot object instead of all the AST nodes of accesses.

Marcus


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] PharoV20.source

[Camille Teruel]

On 13 nov. 2013, at 12:30, Stéphane Ducasse  wrote:

>> 
>> Anyway, even if at the end it takes more memory than the current source 
>> file, we should not forget that having persistant ASTs that you can freely 
>> annotate brings far more than compression, it opens *many* doors :)
>> The annotations on the nodes would take memory too. Well, at least for the 
>> annotation one wants to be persistant.
>> Even with compression, storing all the annotations one would want to have 
>> would take too much memory. 
>> Imagine that you want to stores additional comments and discussions (instead 
>> of "self flag:" everywhere), statistics like code coverage, about which 
>> class a variable had across different executions, type annotations for many 
>> different kind of type systems (and remember its annotations, not intrusive, 
>> no syntax change, pluggable)...
>> That's why I want to have repositories for storing node annotations across 
>> network.
>> Like this we would have a compressed AST format in the image (called Bonsai) 
>> and a mechanism for storing and sharing node annotations on repositories 
>> (project's name: Baobab) 
> 
> Camille can you describe these projects in the Pharo topics on github
> We should find a guy to work on them.

Yes but you only talk about Baobab right? Because Pablo is already working on 
AST compression and Bonsai.

> 
> Stef
> 
> 

Re: [Pharo-dev] Instrumenting field accesses with Opal?

[Camillo Bruni]

On 2013-11-13, at 14:42, Camille Teruel  wrote:
> On 13 nov. 2013, at 14:21, Alexandre Bergel  wrote:
> 
>> Hi!
>> 
>> Is there a way to get notified when fields are accessed?
>> That would be awesome
> 
> You can use the current reflectivity prototype. It's on RMoD CI: 
> https://ci.inria.fr/rmod/job/Reflectivity/
> It should look like something like that:
> 
> YourClass methods do: [ :method |
>   method ast 
>   forAllNodes: [ :node | node isVariable and: [ node isInstance ] 
> ]
>   putAfter: [ RFMetalink expression: 'Transcript crShow: ''iv 
> accessed''' ];
>   installWrapper ].

In the end we should be able to just use the Slot MOP ;)


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] PharoV20.source

[Igor Stasenko]

2 cents.
just want to make a note, it is important to preserve original text
(yes i am talking about formatting, spacing, tabs etc)..
because without it i can easily imagine you can raise compression ration to
the skies..
but as to me the original text is important part of game.



On 13 November 2013 12:58, Marcus Denker  wrote:

>
> On 13 Nov 2013, at 12:02, p...@highoctane.be wrote:
>
> > Very exciting developments.
> >
> > How would you keep "sources" and "changes" segregated BTW? (if we can
> still call them like that).
> >
> changes are modelled by Martin’s system (EPICEA).
>
> Marcus
>
>
>


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Instrumenting field accesses with Opal?

[Camille Teruel]

On 13 nov. 2013, at 14:21, Alexandre Bergel  wrote:

> Hi!
> 
> Is there a way to get notified when fields are accessed?
> That would be awesome

You can use the current reflectivity prototype. It's on RMoD CI: 
https://ci.inria.fr/rmod/job/Reflectivity/
It should look like something like that:

YourClass methods do: [ :method |
method ast 
forAllNodes: [ :node | node isVariable and: [ node isInstance ] 
]
putAfter: [ RFMetalink expression: 'Transcript crShow: ''iv 
accessed''' ];
installWrapper ].

>   
> Alexandre
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

Re: [Pharo-dev] Where is the FileDirectory-based version of ZnFileSystemUtils?

[Mariano Martinez Peck]

On Wed, Nov 13, 2013 at 3:36 AM, Sven Van Caekenberghe  wrote:

>
> On 13 Nov 2013, at 03:08, Mariano Martinez Peck 
> wrote:
>
> > Hi Sven,
> >
> > I was seeing your code of ZnFileSystemUtils ... yes... I probably need
> the same...
> > but I miss the other subclass ;) that one based on FileDirectory. Is
> this implemented by chance? If true, where can I find it?
>
> It is called Zinc-FileSystem-Legacy-SvenVanCaekenberghe.5
>

Thanks Sven, found it.


> I hope it still works.
>

Thanks, me too. Otherwise, I will fix it and let you know.


>
> > Thanks!
> >
> > --
> > Mariano
> > http://marianopeck.wordpress.com
>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

[Pharo-dev] Instrumenting field accesses with Opal?

[Alexandre Bergel]

Hi!

Is there a way to get notified when fields are accessed?
That would be awesome

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-dev] Spec new release :)

[Camillo Bruni]

I added https://github.com/pharo-project/pharo-documentation 

On 2013-11-13, at 02:47, Stéphane Ducasse  wrote:

> Ben it would be good to do it pier format so that we get html and pdf
> and also to avoid to have documentation spread all over.
> 
> Stef
> 
> On Nov 12, 2013, at 11:42 PM, Benjamin  
> wrote:
> 
>> Yes it is planned :)
>> 
>> The idea is to have it ready for the release of Pharo 3.0 (at last).
>> There is a git repo I just opened[1] where the doc will be :)
>> 
>> Every body is free to fork it and to pull-request me :)
>> 
>> Ben
>> [1]https://github.com/BenjaminVanRyseghem/Spec_Documentation
>> 
>> On 12 Nov 2013, at 23:09, kilon alios  wrote:
>> 
>>> Is there any new documentation planned ? 
>>> 
>>> 
>>> On Tue, Nov 12, 2013 at 11:42 PM, Benjamin 
>>>  wrote:
>>> Confirmed and fixed :P
>>> https://pharo.fogbugz.com/default.asp?12153
>>> 
>>> 
>>> Ben
>>> 
>>> On 12 Nov 2013, at 17:08, Martin Dias  wrote:
>>> 
 (Checked in Pharo 30567)
 
 On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias  wrote:
> Thanks Ben. It's neat to have Spec models for tree columns. It was
> strange to instantiate MorphTreeColumnMorph directly from my Spec
> model.
> 
> I found an issue in TreeModel: Only one level of children is shown.
> Reproduce with:
> 
> TreeModel new
>  roots: (1 to: 5);
>  childrenBlock: [ :item | 1+item to: 5+item ];
>  openWithSpec
> 
> Should I report?
> 
> Martín
> 
> On Tue, Nov 12, 2013 at 2:59 PM, Benjamin
>  wrote:
>> It’s this one: https://pharo.fogbugz.com/default.asp?12135
>> 
>> Ben
>> 
>> On 12 Nov 2013, at 14:49, Martin Dias  wrote:
>> 
>> I forgot to specify: in latest Pharo (30565)
>> 
>> On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias  
>> wrote:
>> 
>> I think there is some issue with TreeColumnModel. For example:
>> 
>> TreeModel exampleWithCustomColumnsAndNodes
>> 
>> Raises "ByteSymbol(Object)>>doesNotUnderstand: #adapt:"
>> 
>> Should I report in fogbugz?
>> 
>> thanks,
>> Martín
>> 
>> On Tue, Nov 12, 2013 at 2:21 PM, Stéphane Ducasse
>>  wrote:
>> 
>> Yes this is what I did for the change sorter. I do not like this DSL like
>> way of passing block over block over block
>> over blocks.
>> 
>> I love blocks but methods are named blocks and I prefer them.
>> 
>> Stef
>> 
>> biut that method can be written:
>> 
>> aMenu addGroup: (MenuGroupModel new
>> addItem: (MenuItemModel new
>> name: 'Browse Full';
>> action: [ self browseSelectedObject ];
>> shortcut: $b command mac | $b alt win | $b alt unix);
>> addItem: (MenuItem new
>> name: 'Browse Class';
>> action: [ self browseSelectedObjectClass ])).
>> 
>> and you do not have to declare variables for that (and is a lot better 
>> than
>> using a block, IMO).
>> 
>> 
>> 
>> On Nov 12, 2013, at 9:36 AM, Benjamin 
>> 
>> wrote:
>> 
>> One can just use an object too.
>> 
>> It’s just that otherwise, it pollutes a bit the method with tons of inst
>> vars
>> (and then you forget to use them :P)
>> 
>> Ben
>> 
>> On 12 Nov 2013, at 13:05, Esteban Lorenzano  wrote:
>> 
>> 
>> On Nov 12, 2013, at 4:22 AM, Benjamin 
>> 
>> wrote:
>> 
>> It is not necessary better, but it saves you from having hundreds of temp
>> vars :)
>> 
>> Ben
>> 
>> On 12 Nov 2013, at 01:49, Stéphane Ducasse 
>> wrote:
>> 
>> 
>> Example:
>> aMenu addGroup: [ :aGroup |
>> aGroup addItem: [ :anItem |
>> anItem name: 'Browse Full';
>> action: [ self browseSelectedObject ];
>> shortcut: $b command mac | $b alt win | $b alt unix  ].
>> aGroup addItem: [ :anItem |
>> anItem name: 'Browse Class';
>> action: [ self browseSelectedObjectClass ] ] ].
>> 
>> 
>> I do not see the value of passing block to add element to groups
>> why not the normal way i.e. passing an object. I do not get why executing
>> a block with an object is better?
>> 
>> 
>> he, I thought the same :)
>> 
>> 
>> Stef
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
 
>>> 
>>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-dev] NativeBoost: Documentation Suggestion and Question

[Igor Stasenko]

According to its manual
(
http://portaudio.com/docs/v19-doxydocs/portaudio_8h.html#a0a12735ac191200f696a43b87667b714
)

stream

The address of a PaStream pointer which will receive a pointer to the newly
opened stream.


So, what you need to pass is a pointer to location where pointer will be
stored.
The simplest way how to do it (without explaining you how to use
NBExternalValue)
just do a following:

PaError Pa_OpenDefaultStream(NBExternalAddress * stream ... )

then your call site will look like following:

streamHandle := NBExternalAddress new.

self Pa_opendefaultBlah: streamHandle  ...


The 'NBExternalAddress *' type treated specially, because usually for most
cases
if you pass an instance of NBExternalAddress to any function which expects
some pointer, NB will pass the value of NBExternalAddress, however if type
is
NBExternalAddress * , then NB will pass a pointer where pointer value is
stored (which  effectively means pointer to pointer)

that should do the trick.
But hold on, next thing you will stuck with is callback ... hehe :)
ah.. ok, according to manual, you can simply skip this one by passing NULL
(nil)
for that, again you can just change the function signature and instead of
putting


PaStreamCallback*
*streamCallback*
put nil. (yes, nil literal)



On 13 November 2013 06:11, Sean P. DeNigris  wrote:

> Sean P. DeNigris wrote
> > I'll let you know how it turns out.
>
> Okay, I got a little further. I can initialize and terminate the library.
> Yahoo!!
>
> To load the very basic spike:
> Gofer it
> smalltalkhubUser: 'SeanDeNigris' project: 'PortAudio';
> package: 'PortAudio';
> load.
>
> My next task is to call...
> PaError Pa_OpenDefaultStream(PaStream **stream, "PaStream
> is typedef for
> void"
> int numInputChannels,
> int numOutputChannels,
> ulong   sampleFormat,
> double  sampleRate,
> ulong   framesPerBuffer,
> PaStreamCallbackstreamCallback,
> void *  userData) (see
> http://portaudio.com/docs/v19-doxydocs/open_default_stream.html)
>
> The first argument is most perplexing to me. I haven't seen any NativeBoost
> examples of pointers to pointers. In fact, with pointers to values, it
> seems
> random whether they are derefenced when described in NB.
>
> For example:
>   cairo_t* cairo_create (cairo_surface_t *target);
> becomes (from the IWST paper):
>   self nbCall: #(
> AthensCairoCanvas cairo_create (
>   AthensCairoSurface cairoSurface))
>
> Notice the argument is dereferenced in the NB version.
>
> But (also from the IWST paper):
>   "void cairo_matrix_multiply (
>  cairo_matrix_t *result,
>  const cairo_matrix_t *a,
>  const cairo_matrix_t *b );"
> becomes:
>   self nbCall: #(void cairo_matrix_multiply (AthensCairoMatrix * self,
> AthensCairoMatrix * m , AthensCairoMatrix * self ) )
>
> In this case, none of the arguments are defererenced.
>
> Anyway, I'd really appreciate it if someone would load the code and see
> what the problem is.
>
> "PortAudio example" will run the demo script I'm translating from the
> library docs into Pharo.
>
> Thanks in advance...
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context:
> http://forum.world.st/NativeBoost-Documentation-Suggestion-and-Question-tp4720805p4721585.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>


-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Questions about Athens

[Igor Stasenko]

I doubt it is related to Athens. I think it is initialization problem.
If morph's extent depends on external factors, you should properly
initialize them
before computing it.
It could be that you calling #checkSession before.. which leads to DNU,
because no extent can be computed at given point yet.

On 12 November 2013 12:59, kilon alios  wrote:

> Igor just for the record, I still have not figure out why I had this
> problem in the first place. I was using self extent and that was giving me
> a NB error as I posted in the first stack trace. I changed it to self
> defaultExtent that returns a point with the default size of the area of the
> Morph and voila it worked. I checked the Hierachy and Morph which is the
> super class of Hyperion has an extent method so this should work. So I
> think this may be an Athens bug after all.
>
> So i changed the method from
>
> checkSession
> session == Smalltalk session ifFalse: [surface := AthensCairoSurface
> extent: self extent . session := Smalltalk session  ]
>
> to
>
> checkSession
> session == Smalltalk session ifFalse: [surface := AthensCairoSurface
> extent: self defaultExtent . session := Smalltalk session  ]
>
> and now it works properly for some strange reason. At first I thought it
> was because there was no self extent method but now I see thats not the
> case.
>
>
> On Tue, Nov 12, 2013 at 1:20 PM, Igor Stasenko  wrote:
>
>>
>>
>>
>> On 11 November 2013 21:47, kilon alios  wrote:
>>
>>> Ignore my last messages. Apparently I had an error with my code I just
>>> did not understand the error report. Everything works fone now.
>>>
>>
>> :)
>>
>>
>>> Στις 11 Νοε 2013 4:46 μ.μ., ο χρήστης "kilon alios" <
>>> kilon.al...@gmail.com> έγραψε:
>>>
>>>  sorry previous stack was for slightly diffirent code this is the
 correct one

 UndefinedObject(Object)>>doesNotUnderstand: #drawDuring:
 Hyperion>>render
 Hyperion>>drawOn:
 FormCanvas(Canvas)>>draw:
 FormCanvas(Canvas)>>drawMorph:
 Hyperion(Morph)>>fullDrawOn: in Block: [ ...
 FormCanvas>>roundCornersOf:in:during:
 FormCanvas(Canvas)>>roundCornersOf:during:
 Hyperion(Morph)>>fullDrawOn: in Block: [ ...
 BlockClosure>>on:do:
 Hyperion(Morph)>>fullDrawOn:
 FormCanvas(Canvas)>>fullDraw:
 FormCanvas(Canvas)>>fullDrawMorph:
 SystemWindow(Morph)>>drawSubmorphsOn: in Block: [ :m | canvas
 fullDrawMorph: m ]
 Array(SequenceableCollection)>>reverseDo:
 SystemWindow(Morph)>>drawSubmorphsOn: in Block: [ :canvas | submorphs
 reverseDo: [ :m | canvas ful...etc...
 FormCanvas>>clipBy:during:
 SystemWindow(Morph)>>drawSubmorphsOn:
 SystemWindow(Morph)>>fullDrawOn: in Block: [ ...
 FormCanvas>>roundCornersOf:in:during:
 FormCanvas(Canvas)>>roundCornersOf:during:
 SystemWindow(Morph)>>fullDrawOn: in Block: [ ...
 BlockClosure>>on:do:
 SystemWindow(Morph)>>fullDrawOn:
 FormCanvas(Canvas)>>fullDraw:
 FormCanvas(Canvas)>>fullDrawMorph:
 WorldState>>drawWorld:submorphs:invalidAreasOn: in Block: drawWorld:
 aWorld submorphs: submorphs invalidArea...etc...
 Rectangle>>allAreasOutsideList:startingAt:do:
 Rectangle>>allAreasOutsideList:do:
 WorldState>>drawWorld:submorphs:invalidAreasOn: in Block: [ :dirtyRect
 | ...



 On Mon, Nov 11, 2013 at 4:43 PM, kilon alios wrote:

> Igor I am trying your session code but it does not work for me. I
> still get the red box of doom. This is the method
>
> checkSession
>
> session == Smalltalk session ifFalse: [
>  surface := surface := AthensCairoSurface extent: self extent. .
>  session := Smalltalk session.
>  ]
>
> and This is my full stack
>
> NBFFICallout class>>signalError:
> NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode:
> NBFFICalloutAPI>>function:module:
> AthensCairoSurface class(Object)>>nbCall:
> AthensCairoSurface class>>primImage:width:height:
> NBFFICallout class(NBNativeCodeGen class)>>retrySend:
> AthensCairoSurface class>>extent:format:
> AthensCairoSurface class>>extent:
> Hyperion>>mouseDown:
> Hyperion(Morph)>>handleMouseDown:
> MouseButtonEvent>>sentTo:
> Hyperion(Morph)>>handleEvent:
> MorphicEventDispatcher>>dispatchMouseDown:with:
> MorphicEventDispatcher>>dispatchEvent:with:
> Hyperion(Morph)>>processEvent:using:
> MorphicEventDispatcher>>dispatchMouseDown:with:
> MorphicEventDispatcher>>dispatchEvent:with:
> SystemWindow(Morph)>>processEvent:using:
> SystemWindow(Morph)>>processEvent:
> SystemWindow>>mouseDown: in Block: [ ...
> BlockClosure>>ensure:
> SystemWindow>>mouseDown:
> SystemWindow(Morph)>>handleMouseDown:
> MouseButtonEvent>>sentTo:
> SystemWindow(Morph)>>handleEvent:
> MorphicEventDispatcher>>dispatchMouseDown:with:
> MorphicEventDispatcher>>dispatchEvent:with:
> SystemWindow(Morph)>>processEvent:using:
> MorphicEve

Re: [Pharo-dev] Spec new release :)

[Benjamin]

Stef, what is the advantages of writing it in Pier compared to markdown ?

Ben

Re: [Pharo-dev] Spec new release :)

[Benjamin]

Ben

On 13 Nov 2013, at 12:43, Christophe Demarey  
wrote:

> Hi,
> 
>  I have some questions:
> 
> 1/ Before the removal of morphic dependencies in spec, I used aNode 
> selectedNode parentNode item to get the parent of the selected item. What is 
> the new way to do that?

I think I forgot about this one :)
The fix is easy though.

Can you open an issue, I will have a look this evening :)


> 2/ I also defined specific nodes for a Tree model. These nodes overrode the 
> childrenItems method to provide children elements. It looks like this method 
> is not used anymore in TreeNodeModel. What should I now use to provide 
> children elements in a TreeNodeModel?

You used to have Morphic node specific classes.
Now there is only TreeNodeModel.

So instead of creating a subclass, you will have to specify the TreeNodeModels 
you want
(and specifying children is #children:)

It is also possible that I forgot some scenarios, in this case, you can send 
another email,
or wait tip next week so we can sit together :)


Ben

> 
> Thanks,
> Christophe.

Re: [Pharo-dev] PharoV20.source

[Marcus Denker]

On 13 Nov 2013, at 12:02, p...@highoctane.be wrote:

> Very exciting developments.
> 
> How would you keep "sources" and "changes" segregated BTW? (if we can still 
> call them like that).
> 
changes are modelled by Martin’s system (EPICEA).

Marcus

Re: [Pharo-dev] Spec new release :)

[Christophe Demarey]

Hi,

 I have some questions:

1/ Before the removal of morphic dependencies in spec, I used aNode 
selectedNode parentNode item to get the parent of the selected item. What is 
the new way to do that?

2/ I also defined specific nodes for a Tree model. These nodes overrode the 
childrenItems method to provide children elements. It looks like this method is 
not used anymore in TreeNodeModel. What should I now use to provide children 
elements in a TreeNodeModel?

Thanks,
Christophe.

smime.p7s
Description: S/MIME cryptographic signature

Re: [Pharo-dev] PharoV20.source

[Stéphane Ducasse]

> 
> Anyway, even if at the end it takes more memory than the current source file, 
> we should not forget that having persistant ASTs that you can freely annotate 
> brings far more than compression, it opens *many* doors :)
> The annotations on the nodes would take memory too. Well, at least for the 
> annotation one wants to be persistant.
> Even with compression, storing all the annotations one would want to have 
> would take too much memory. 
> Imagine that you want to stores additional comments and discussions (instead 
> of "self flag:" everywhere), statistics like code coverage, about which class 
> a variable had across different executions, type annotations for many 
> different kind of type systems (and remember its annotations, not intrusive, 
> no syntax change, pluggable)...
> That's why I want to have repositories for storing node annotations across 
> network.
> Like this we would have a compressed AST format in the image (called Bonsai) 
> and a mechanism for storing and sharing node annotations on repositories 
> (project's name: Baobab) 

Camille can you describe these projects in the Pharo topics on github
We should find a guy to work on them.

Stef

Re: [Pharo-dev] petit parser repository

[Norbert Hartl]

Am 12.11.2013 um 13:53 schrieb Stephan Eggermont :

> Just try with .44
> 
Thanks very much Stephan,  looks pretty good for me.

Norbert

Re: [Pharo-dev] multiple files in pillar

[Stéphane Ducasse]

On Nov 13, 2013, at 11:28 AM, Tudor Girba  wrote:

> Hi,
> 
> On Wed, Nov 13, 2013 at 11:18 AM, Stéphane Ducasse 
>  wrote:
> 
>> 
>> At the moment, Pillar assumes that one file is one chapter. When generating 
>> PDF, an index .tex file is required to construct the overall book with table 
>> of contents and others such elements.
>> 
>> As far as I see, in HTML, there is no possibility of generating this
>> 
>> Is there a plan to extend Pillar to support a book with multiple files?
> 
> this was not plan but we could
> Now if someone needs that he should have a look and help
> 
> Ok.
> 
>> What about references? I saw somewhere that there existed an intention of 
>> supporting references, but I did not see an example yet.
> 
> do you mean ref{} or cite{}
> 
> I mean cite{}
>  
> We want to add a kind of  generic tagging so that we can express
>   cite{}  
>   comment{}
>   …
> 
> Interesting. I would be very interested in that.

me too :)
so if you have an idea of the syntax
@cite@value@
>  
>> Are they supported?
> 
> I do not think so right now.
> 
> Ok.
> 
> Doru
>  
>> 
>> Cheers,
>> Doru
>> 
>> -- 
>> www.tudorgirba.com
>> 
>> "Every thing has its own flow"
>> 
>> 
>> 
>> -- 
>> www.tudorgirba.com
>> 
>> "Every thing has its own flow"
> 
> 
> 
> 
> -- 
> www.tudorgirba.com
> 
> "Every thing has its own flow"

Re: [Pharo-dev] PharoV20.source

[p...@highoctane.be]

Very exciting developments.

How would you keep "sources" and "changes" segregated BTW? (if we can still
call them like that).



---
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Mail:p...@highoctane.be | Web: http://philippeback.eu
Blog: http://philippeback.be | Twitter: @philippeback
Youtube: http://www.youtube.com/user/philippeback/videos

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Pharo Consortium Member - http://consortium.pharo.org/
Featured on the Software Process and Measurement Cast -
http://spamcast.libsyn.com
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value
Added Reseller




On Wed, Nov 13, 2013 at 11:55 AM, Camille Teruel
wrote:

>
> On 12 nov. 2013, at 23:54, Clément Bera  wrote:
>
> Hello,
>
> Currently the idea is to put the source file as a compressed AST in the
> image.
>
> The status is:
> - standard AST is 300Mb for the whole image, which is too much
> - standard AST with nodes shared between RBMethodNodes (made by Camille)
> is 16Mb, so already half the size of the current source
>
>
> In fact 16 Mb is a lucky guess too.
> It currently takes 13Mb without indentation and comments.
>
> - same as last one but with additional bit compression: not done yet ! It
> should be around 4Mb (but that's a lucky guess), growing the size of the
> image from 16Mb to 20Mb, which is okay.
>
>
> Pablo is currently working on AST compression.
> We could use Huffman coding or something else.
>
> Anyway, even if at the end it takes more memory than the current source
> file, we should not forget that having persistant ASTs that you can freely
> annotate brings far more than compression, it opens *many* doors :)
> The annotations on the nodes would take memory too. Well, at least for the
> annotation one wants to be persistant.
> Even with compression, storing all the annotations one would want to have
> would take too much memory.
> Imagine that you want to stores additional comments and discussions
> (instead of "self flag:" everywhere), statistics like code coverage, about
> which class a variable had across different executions, type annotations
> for many different kind of type systems (and remember its annotations, not
> intrusive, no syntax change, pluggable)...
> That's why I want to have repositories for storing node annotations across
> network.
> Like this we would have a compressed AST format in the image (called
> Bonsai) and a mechanism for storing and sharing node annotations on
> repositories (project's name: Baobab)
>
> The source file should not be in the VM. One image can use only 1 source
> file, but 1 VM can run several images using different source files.
> Therefore you would need to add multiple source files in the VM, which ends
> up nowhere.
>
>
>
> 2013/11/12 Stéphane Ducasse 
>
>> you want as less as possible thing in the vm.
>>
>> Stef
>>
>> On Nov 12, 2013, at 8:46 PM, Alexandre Bergel 
>> wrote:
>>
>> > Hi!
>> >
>> > Why not to include this file in the VM?
>> > It often happens to me that this place is wrongly placed. When this
>> happens, Pharo just shows a white screen, without letting what is the error.
>> >
>> > Alexandre
>> > --
>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> > Alexandre Bergel  http://www.bergel.eu
>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> >
>> >
>> >
>> >
>>
>>
>>
>
>

Re: [Pharo-dev] PharoV20.source

[Camille Teruel]

On 12 nov. 2013, at 23:54, Clément Bera  wrote:

> Hello,
> 
> Currently the idea is to put the source file as a compressed AST in the 
> image. 
> 
> The status is:
> - standard AST is 300Mb for the whole image, which is too much
> - standard AST with nodes shared between RBMethodNodes (made by Camille) is 
> 16Mb, so already half the size of the current source

In fact 16 Mb is a lucky guess too. 
It currently takes 13Mb without indentation and comments. 

> - same as last one but with additional bit compression: not done yet ! It 
> should be around 4Mb (but that's a lucky guess), growing the size of the 
> image from 16Mb to 20Mb, which is okay.

Pablo is currently working on AST compression.
We could use Huffman coding or something else. 

Anyway, even if at the end it takes more memory than the current source file, 
we should not forget that having persistant ASTs that you can freely annotate 
brings far more than compression, it opens *many* doors :)
The annotations on the nodes would take memory too. Well, at least for the 
annotation one wants to be persistant.
Even with compression, storing all the annotations one would want to have would 
take too much memory. 
Imagine that you want to stores additional comments and discussions (instead of 
"self flag:" everywhere), statistics like code coverage, about which class a 
variable had across different executions, type annotations for many different 
kind of type systems (and remember its annotations, not intrusive, no syntax 
change, pluggable)...
That's why I want to have repositories for storing node annotations across 
network.
Like this we would have a compressed AST format in the image (called Bonsai) 
and a mechanism for storing and sharing node annotations on repositories 
(project's name: Baobab) 

> The source file should not be in the VM. One image can use only 1 source 
> file, but 1 VM can run several images using different source files. Therefore 
> you would need to add multiple source files in the VM, which ends up nowhere.
> 
> 
> 
> 2013/11/12 Stéphane Ducasse 
> you want as less as possible thing in the vm.
> 
> Stef
> 
> On Nov 12, 2013, at 8:46 PM, Alexandre Bergel  wrote:
> 
> > Hi!
> >
> > Why not to include this file in the VM?
> > It often happens to me that this place is wrongly placed. When this 
> > happens, Pharo just shows a white screen, without letting what is the error.
> >
> > Alexandre
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
> 
> 
> 

Re: [Pharo-dev] multiple files in pillar

[Tudor Girba]

Hi,

On Wed, Nov 13, 2013 at 11:18 AM, Stéphane Ducasse <
stephane.duca...@inria.fr> wrote:

>
>
>> At the moment, Pillar assumes that one file is one chapter. When
>> generating PDF, an index .tex file is required to construct the overall
>> book with table of contents and others such elements.
>>
>> As far as I see, in HTML, there is no possibility of generating this
>>
>> Is there a plan to extend Pillar to support a book with multiple files?
>>
>
> this was not plan but we could
> Now if someone needs that he should have a look and help
>

Ok.

What about references? I saw somewhere that there existed an intention of
>> supporting references, but I did not see an example yet.
>>
>
> do you mean ref{} or cite{}
>

I mean cite{}


> We want to add a kind of  generic tagging so that we can express
> cite{}
> comment{}
> …
>

Interesting. I would be very interested in that.


> Are they supported?
>>
>
> I do not think so right now.
>

Ok.

Doru


>
>> Cheers,
>> Doru
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-dev] multiple files in pillar

[Stéphane Ducasse]

> 
> At the moment, Pillar assumes that one file is one chapter. When generating 
> PDF, an index .tex file is required to construct the overall book with table 
> of contents and others such elements.
> 
> As far as I see, in HTML, there is no possibility of generating this
> 
> Is there a plan to extend Pillar to support a book with multiple files?

this was not plan but we could
Now if someone needs that he should have a look and help

> What about references? I saw somewhere that there existed an intention of 
> supporting references, but I did not see an example yet.

do you mean ref{} or cite{}

We want to add a kind of  generic tagging so that we can express
cite{}  
comment{}
…

> Are they supported?

I do not think so right now.

> 
> Cheers,
> Doru
> 
> -- 
> www.tudorgirba.com
> 
> "Every thing has its own flow"
> 
> 
> 
> -- 
> www.tudorgirba.com
> 
> "Every thing has its own flow"

Re: [Pharo-dev] smalltalkhub.com down

[Norbert Hartl]

Am 13.11.2013 um 10:59 schrieb p...@highoctane.be:

> What would be cool is to have a kind of static mirror for all the mcz's so 
> that we can go there in case of trouble.
> 
I didn’t look at the architecture of smalltalkhub. I only know everything is 
put into mongo and I can imagine the rationale behind it. Nevertheless putting 
it into mongo can happen in different ways. Using GridFS would be a good way 
storing plain files in the DB with the opportunity to cluster the GridFS over 
multiple hosts. Additionally there are modules for apache and nginx to access 
GridFS inside mongo. So even if the pharo image dies or something similar the 
files would be still accessible.

Norbert

> 
> 
> ---
> Philippe Back
> Dramatic Performance Improvements
> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
> Mail:p...@highoctane.be | Web: http://philippeback.eu
> Blog: http://philippeback.be | Twitter: @philippeback
> Youtube: http://www.youtube.com/user/philippeback/videos
> 
> High Octane SPRL
> rue cour Boisacq 101 | 1301 Bierges | Belgium
> 
> Pharo Consortium Member - http://consortium.pharo.org/
> Featured on the Software Process and Measurement Cast - 
> http://spamcast.libsyn.com
> Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added 
> Reseller
>  
> 
> 
> 
> On Wed, Nov 13, 2013 at 10:26 AM, Nicolas Petton  
> wrote:
> Hi guys,
> 
> I'm working on a new release of smalltalkhub. I will also check what is
> making it crash and monitor the website.
> 
> I think I will also move the service to Inria infrastructure in the
> short future.
> 
> Cheers,
> Nico
> 
> Mariano Martinez Peck writes:
> 
> > On Tue, Nov 12, 2013 at 11:05 PM, Stéphane Ducasse <
> > stephane.duca...@inria.fr> wrote:
> >
> >> +1
> >> I was chatting today with nico and he told me that he is working on a new
> >> release
> >> and that he really wants to understand what brings the instability and he
> >> is preparing some crash tests.
> >> But we are the crash tests.
> >>
> >>
> > Ahhh ok, then I shut up :)
> >
> >
> >
> >
> >> Stef
> >>
> >> Cannot we simply run monit in the server? It is insane to wait someone to
> >> restart it manually
> >>
> >>
> >> On Tue, Nov 12, 2013 at 10:42 PM, Nicolas Cellier <
> >> nicolas.cellier.aka.n...@gmail.com> wrote:
> >>
> >>> http://www.downforeveryoneorjustme.com/smalltalkhub.com
> >>>
> >>
> >>
> >>
> >> --
> >> Mariano
> >> http://marianopeck.wordpress.com
> >>
> >>
> >>
> 
> 
> --
> Nicolas Petton
> http://nicolas-petton.fr
> 
> 

Re: [Pharo-dev] smalltalkhub.com down

[p...@highoctane.be]

What would be cool is to have a kind of static mirror for all the mcz's so
that we can go there in case of trouble.



---
Philippe Back
Dramatic Performance Improvements
Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Mail:p...@highoctane.be | Web: http://philippeback.eu
Blog: http://philippeback.be | Twitter: @philippeback
Youtube: http://www.youtube.com/user/philippeback/videos

High Octane SPRL
rue cour Boisacq 101 | 1301 Bierges | Belgium

Pharo Consortium Member - http://consortium.pharo.org/
Featured on the Software Process and Measurement Cast -
http://spamcast.libsyn.com
Sparx Systems Enterprise Architect and Ability Engineering EADocX Value
Added Reseller




On Wed, Nov 13, 2013 at 10:26 AM, Nicolas Petton
wrote:

> Hi guys,
>
> I'm working on a new release of smalltalkhub. I will also check what is
> making it crash and monitor the website.
>
> I think I will also move the service to Inria infrastructure in the
> short future.
>
> Cheers,
> Nico
>
> Mariano Martinez Peck writes:
>
> > On Tue, Nov 12, 2013 at 11:05 PM, Stéphane Ducasse <
> > stephane.duca...@inria.fr> wrote:
> >
> >> +1
> >> I was chatting today with nico and he told me that he is working on a
> new
> >> release
> >> and that he really wants to understand what brings the instability and
> he
> >> is preparing some crash tests.
> >> But we are the crash tests.
> >>
> >>
> > Ahhh ok, then I shut up :)
> >
> >
> >
> >
> >> Stef
> >>
> >> Cannot we simply run monit in the server? It is insane to wait someone
> to
> >> restart it manually
> >>
> >>
> >> On Tue, Nov 12, 2013 at 10:42 PM, Nicolas Cellier <
> >> nicolas.cellier.aka.n...@gmail.com> wrote:
> >>
> >>> http://www.downforeveryoneorjustme.com/smalltalkhub.com
> >>>
> >>
> >>
> >>
> >> --
> >> Mariano
> >> http://marianopeck.wordpress.com
> >>
> >>
> >>
>
>
> --
> Nicolas Petton
> http://nicolas-petton.fr
>
>

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 5061af: 30569

[GitHub]

  Branch: refs/heads/3.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 5061afcc6b94bf49966bc30282409e08a25b4912
  
https://github.com/pharo-project/pharo-core/commit/5061afcc6b94bf49966bc30282409e08a25b4912
  Author: Jenkins Build Server 
  Date:   2013-11-13 (Wed, 13 Nov 2013)

  Changed paths:
A ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script225.st
A ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
updates/update30569.st
M 
ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M 
Spec-Core.package/ComposableModel.class/instance/private-focus/takeKeyboardFocus.st
M Spec-Inspector.package/EyeTreeInspector.class/instance/accessing/tree.st
M Spec-PolyWidgets.package/SearchableTree.class/instance/protocol/roots_.st

  Log Message:
  ---
  30569
11782 SearchableTree not working
https://pharo.fogbugz.com/f/cases/11782

12132 MNU: TreeNodeModel>>#item
https://pharo.fogbugz.com/f/cases/12132

http://files.pharo.org/image/30/30569.zip

Re: [Pharo-dev] smalltalkhub.com down

[Nicolas Petton]

Hi guys,

I'm working on a new release of smalltalkhub. I will also check what is
making it crash and monitor the website.

I think I will also move the service to Inria infrastructure in the
short future.

Cheers,
Nico

Mariano Martinez Peck writes:

> On Tue, Nov 12, 2013 at 11:05 PM, Stéphane Ducasse <
> stephane.duca...@inria.fr> wrote:
>
>> +1
>> I was chatting today with nico and he told me that he is working on a new
>> release
>> and that he really wants to understand what brings the instability and he
>> is preparing some crash tests.
>> But we are the crash tests.
>>
>>
> Ahhh ok, then I shut up :)
>
>
>
>
>> Stef
>>
>> Cannot we simply run monit in the server? It is insane to wait someone to
>> restart it manually
>>
>>
>> On Tue, Nov 12, 2013 at 10:42 PM, Nicolas Cellier <
>> nicolas.cellier.aka.n...@gmail.com> wrote:
>>
>>> http://www.downforeveryoneorjustme.com/smalltalkhub.com
>>>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>>


-- 
Nicolas Petton
http://nicolas-petton.fr

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

[GitHub]

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

[Pharo-dev] [pharo-project/pharo-core] 7a468a: 30568

[GitHub]

  Branch: refs/heads/3.0
  Home:   https://github.com/pharo-project/pharo-core
  Commit: 7a468acff5960957559f8cd3760f3ce487570864
  
https://github.com/pharo-project/pharo-core/commit/7a468acff5960957559f8cd3760f3ce487570864
  Author: Jenkins Build Server 
  Date:   2013-11-13 (Wed, 13 Nov 2013)

  Changed paths:
R 
Ring-Core-Kernel.package/RGClassDescriptionDefinition.class/instance/instance 
variables/instVarNamed_.st
A 
Ring-Core-Kernel.package/RGClassDescriptionDefinition.class/instance/instance 
variables/instanceVariableNamed_.st
M 
Ring-Core-Kernel.package/RGClassDescriptionDefinition.class/instance/instance 
variables/removeInstVarNamed_.st
A 
Ring-Core-Kernel.package/RGDefinition.class/instance/converting/asRingDefinition.st
A 
Ring-Tests-Kernel.package/RGClassDefinitionTest.class/instance/testing/testAsRingDefinition.st
M 
Ring-Tests-Kernel.package/RGClassDefinitionTest.class/instance/testing/testWithClassInstanceVariables.st
M 
Ring-Tests-Kernel.package/RGClassDefinitionTest.class/instance/testing/testWithInstanceVariables.st
M 
Ring-Tests-Kernel.package/RGVariableDefinitionTest.class/instance/testing/testVariableEquality.st
A ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
scripts/script224.st
A ScriptLoader30.package/ScriptLoader.class/instance/pharo - 
updates/update30568.st
M 
ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M 
Spec-Core.package/TextModel.class/instance/protocol/codePaneMenu_shifted_.st
M 
Spec-Core.package/TreeModel.class/class/examples/exampleWithCustomColumnsAndNodesAndChildren.st
A 
Spec-Core.package/TreeModel.class/class/examples/exampleWithNoSpecifiedNodes.st
M Spec-Core.package/TreeModel.class/instance/initialization/initialize.st
M Spec-Core.package/TreeNodeModel.class/instance/initialize/initialize.st
M Spec-Core.package/TreeNodeModel.class/instance/procotol/children_.st
M Spec-MorphicAdapters.package/MorphicTreeNodeAdapter.class/instance/widget 
API/childrenBlock.st
M 
Spec-MorphicAdapters.package/SpecTreeNodeModel.class/instance/building/childNodeFromItem_.st

  Log Message:
  ---
  30568
12153 Issue with the old TreeModel API
https://pharo.fogbugz.com/f/cases/12153

12151 Ring definitions should respond to #asRingDefinition
https://pharo.fogbugz.com/f/cases/12151

12152 RGClassDescriptionDefinition should not override #instVarNamed:
https://pharo.fogbugz.com/f/cases/12152

http://files.pharo.org/image/30/30568.zip

Re: [Pharo-dev] Issue with last line / line ending between FileTree and other repositoroes

[Goubier Thierry]

Hi Mariano,

it is probably a bug in the way the changes are computed: in MC usually, 
if the timestamp of a method changes, then this is a change, even if the 
source code are exactly the same... No need to search for a missing end 
of line character :).


I have been pushing for integration of a fix, but I have to check, 
depending on your version of Pharo, whether it was integrated or not 
(the fix is less obvious than I thought at first because it plays with a 
MCDefinition instance cache and may break tests).


Try to look for MCMethodDefinition>>= and see there if the test check 
for timestamp equality before testing for source equality.


Thierry

Le 12/11/2013 21:09, Mariano Martinez Peck a écrit :

Hi Dale,

During Smalltalks, you helped me to start loading my code into GemStone.
For that, we created a temp FileTree repository so that we could easily
edit/save and retry the load. That saved us modifying the code
elsewhere, commit, load again etc... Cool!
But now I have a problem... I am trying to merge from filetree to my
original repo. And when I do a diff (Monticello "Changes"), ALL methods
look like modified. FileTree either:

- Removed last empty lines
- Changed the last dot of the last line.
- Removed last space of the last line

So...in summary, it is like if it has changed always the very last
character (whether it is a space, a dot or an empty line). Maybe this is
related to crlf I don't know. But it is a pain because it looks like I
am committing 5k changes! hahaha and I cannot easily see what I have
really changed.

Is this a known problem? Any workaround?

I will send you by private email some screenshots.

Thanks!

--
Mariano
http://marianopeck.wordpress.com


--
Thierry Goubier
CEA list
Laboratoire des Fondations des Systèmes Temps Réel Embarqués
91191 Gif sur Yvette Cedex
France
Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95