Re: [Pharo-users] Wandering Through Dependency Hell

[Tudor Girba]

Hi,

> On May 11, 2017, at 3:55 AM, Juraj Kubelka  wrote:
> 
> Hi,
> 
> I do not understand much you problem. But reading about your commit strategy, 
> you can use Gofer object and its push method to sync properly local changes 
> to a remote repository. Check Pharo books. There are examples. 
> 
> If you inspect a configuration object, there used to be a GT-Inspector 
> extension with dependency visualization. Maybe this is present only in the 
> Moose image. 

Indeed, this is available in the Moose image by default, but can also be loaded 
in plain Pharo if you load the complete version of GTInspector.

Cheers,
Doru


> Cheers,
> Juraj
> 
> --
> Juraj Kubelka
> 
>> El 09-05-2017, a las 22:42, Evan Donahue  escribió:
>> 
>> Hello,
>> 
>> I was wondering if there was a resource somewhere that laid out a best 
>> practice for how to manage version control in Pharo. I know *how* to use 
>> Monticello and Versionner, but something about the way I use them inevitably 
>> dooms my efforts to the darkest circles of dependency hell, where strange 
>> and gruesome partial versions of old and abandoned branches come back to 
>> haunt me like some kind of object oriented night of the living dead. 
>> 
>> In particular, I usually commit daily to a local repository on my disk, and 
>> only occasionally to a remote repository like smalltalkhub. It has come to 
>> my attention that this only commits recent changes, with the result that no 
>> single repository actually has the current working code that I see in my 
>> image. I am in that situation now, where loading the latest version revives 
>> some distant and broken code where good, currently working code should be. 
>> If anyone knows how to figure out how to force all the current good code in 
>> my image into one massive commit, so that other people can check out the 
>> current, working version, please do not hesitate to let me know.
>> 
>> Thanks,
>> Evan
> 

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

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

Re: [Pharo-users] Wandering Through Dependency Hell

[Juraj Kubelka]

Hi,

I do not understand much you problem. But reading about your commit strategy, 
you can use Gofer object and its push method to sync properly local changes to 
a remote repository. Check Pharo books. There are examples. 

If you inspect a configuration object, there used to be a GT-Inspector 
extension with dependency visualization. Maybe this is present only in the 
Moose image. 

Cheers,
Juraj

--
Juraj Kubelka

> El 09-05-2017, a las 22:42, Evan Donahue  escribió:
> 
> Hello,
> 
> I was wondering if there was a resource somewhere that laid out a best 
> practice for how to manage version control in Pharo. I know *how* to use 
> Monticello and Versionner, but something about the way I use them inevitably 
> dooms my efforts to the darkest circles of dependency hell, where strange and 
> gruesome partial versions of old and abandoned branches come back to haunt me 
> like some kind of object oriented night of the living dead. 
> 
> In particular, I usually commit daily to a local repository on my disk, and 
> only occasionally to a remote repository like smalltalkhub. It has come to my 
> attention that this only commits recent changes, with the result that no 
> single repository actually has the current working code that I see in my 
> image. I am in that situation now, where loading the latest version revives 
> some distant and broken code where good, currently working code should be. If 
> anyone knows how to figure out how to force all the current good code in my 
> image into one massive commit, so that other people can check out the 
> current, working version, please do not hesitate to let me know.
> 
> Thanks,
> Evan

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Dimitris Chloupis]

This is revelation to me. I am enduring 10 minute turnaround for every edit
> I make in *.java, xml, jsp, js files. 4 minute compile and 6 minute web
> server update. How can I get that shortened to 10 seconds say? What links
> can help? What search terms to google?
>

10 minutes o_O wow, I can feel your suffering

I do not know Java, I know it but only the very bare bones. What you should
be looking for is any way of dynamic linking.

Usually that means the ability to reload code on runtime, thats what DLLs
are doing. Generally dynamic languages do this out of the box, for example
python can reload its modules on runtime so live coding in python is very
simple. Only a single command.

Dynamic linking is a very basic functionality because its used for
supporting scripting , plugins, addons , in short anything dynamic. I just
googled "java dynamic code loading" which is what live coding is and this
article came up , enjoy

http://www.javaworld.com/article/2071777/design-patterns/add-dynamic-java-code-to-your-application.html


"Kilion,
In Haskell (a language that I love, just as Smalltalk) you have the REPL.
The workflow is, while you are working on the project, you periodically load
that file into the REPL and check. After that you compile. Haskell works
with a strong type inference feature, however most Haskellers will say that
the best practice is to annotate all functions. Also if you are on macOS you
have: http://haskellformac.com/ which is awesome, really a great piece of
software. There was even a project called Kronos that was essentially the
same as IPython but with a Haskell kernel I don't know the status of that
project as of today"

Problem with a REPL is that it makes me feel disconnected. I prefer working
inside my source code directly and in an instant , no delays , no
compromises and multi steps. hence why I love to live code. Plus why bother
with a REPL when you can just live code ? I see no advantage but you can
enlighten me :)

"Hi kilon,
Some weeks ago I tried the C live programming technique for the Ludum Dare.
It works very well. For that occasion I wrote this short article
https://ldjam.com/events/ludum-dare/38/smalcoded-a-small-eco-destroyed-world/a-diabolical-game-for-a-diabolical-experiment
. The game ended pretty well in my opinion:
https://ldjam.com/events/ludum-dare/38/smalcoded-a-small-eco-destroyed-world
."

Bookmarked to check when I log in my Windows (I use mainly macos)

"I work for a video game company that is using Unreal Engine 4, we do not
use the C++ live coding features. I do not like the way that they
implemented live coding, and the bindings for their Blueprint visual
language. We all hate the long compilation times of UE4, the fact that they
use their own undocumented makefile system which is using a bunch C# files
for building their project. We also do not like the fact that from time to
time, we see that we are missing some #includes because of the unity builds
that are done by the unreal build system (merging several .cpp before
compiling them)."

Yes the live coding feature of Unreal is far from impressive, do not know
why they made it so limited and focused only for their editor. Also the
inability to not be able to change blueprints run time is annoying too as
is the build system. But I can still do my own way of live coding with C++
which is much more simple and much more flexible.

"The biggest problem of these other language language is the lack of
reflection information at runtime. The second other problem, is the lack of
#become:, for swapping objects when their data layout changes.

Elf files, PE files (.exe, .dll) and other executable formats are process
images with a symbol table and relocation metadata.

If the operating system allowed to modify in an easy way the symbol table
of the current loaded process, it could be even cooler. In Linux, dlopen is
implemented in terms of open() and mmap().

Best regards,
Ronie"

Reflection is indeed another beast and an area I have not touched yet. To
be fair however, I rarely use reflection and I avoid meta programming.

On the matter of symbol table its my understanding that DLLs come with
their own symbol tables.

It appears to me that you try to modify the executable , that's not my way
of doing live coding with C++.

Also to be clear about, my way of live coding is strictly Spartan. Which
means that in the main loop the only thing that it should be in are:

1) the detection of changes to source code text files (usually checking the
date and time format , plus size of the source code file should be enough)
2) the trigger of the relevant DLL compilation source code  (simple
commands passed to command line, this also means the compilation is
automatic)
3) the reload of the DLL after compilation (again one command)
4) the capture of exception that will not allow the executable or the DLL
to crash even if the DLL does something very bad ( a couple of lines of
code)
5) and finally a singe pointer to a memory 

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Ronie Salgado]

Hi kilon,

Some weeks ago I tried the C live programming technique for the Ludum Dare.
It works very well. For that occasion I wrote this short article
https://ldjam.com/events/ludum-dare/38/smalcoded-a-small-eco-destroyed-world/a-diabolical-game-for-a-diabolical-experiment
. The game ended pretty well in my opinion:
https://ldjam.com/events/ludum-dare/38/smalcoded-a-small-eco-destroyed-world
.

Why C++ coders still endure long compile times when they could test code in
> an instant through live coding ? Well in games C++ live coding is actually
> very popular, so some are already aware of the huge advantages of live
> coding.
>
I work for a video game company that is using Unreal Engine 4, we do not
use the C++ live coding features. I do not like the way that they
implemented live coding, and the bindings for their Blueprint visual
language. We all hate the long compilation times of UE4, the fact that they
use their own undocumented makefile system which is using a bunch C# files
for building their project. We also do not like the fact that from time to
time, we see that we are missing some #includes because of the unity builds
that are done by the unreal build system (merging several .cpp before
compiling them).


> Another shock for me is how simple it is to implement an image file format
> for other languages. The shock was that the OS already uses image files
> like pharo image that calls them "memory mapped files" they are used for
> sharing memory which in turn is what is used for DLLs. The advantage over
> the pharo image is that it crash prone, because it is handled by the OS and
> not the language or the VM. Which means that even if your app crashes the
> image is still saved and you lose no live data which is not the case with
> pharo image. The disadvantage is that of course they are not OOP friendly
> as the pharo image is and they are not language specific as pharo image is.
>
The biggest problem of these other language language is the lack of
reflection information at runtime. The second other problem, is the lack of
#become:, for swapping objects when their data layout changes.

Elf files, PE files (.exe, .dll) and other executable formats are process
images with a symbol table and relocation metadata.

If the operating system allowed to modify in an easy way the symbol table
of the current loaded process, it could be even cooler. In Linux, dlopen is
implemented in terms of open() and mmap().

Best regards,
Ronie


2017-05-10 16:48 GMT-03:00 p...@highoctane.be :

> Or BeanShell
>
> http://www.beanshell.org/
>
> or Groovy
> https://zeroturnaround.com/rebellabs/scripting-your-java-
> application-with-groovy/
>
> or Spring-Shell
> https://projects.spring.io/spring-shell/
>
> Example app I am using (and extending) for Hadoop work:
> https://github.com/sequenceiq/ambari-shell
>
> When one looks inside a command, this is something easily achievable with
> pragmas.
>
> https://github.com/sequenceiq/ambari-shell/blob/master/src/
> main/java/com/sequenceiq/ambari/shell/commands/BasicCommands.java
>
> There is nothing extraordinary in these pieces of tech ("pas de quoi
> casser trois pattes à un canard" in French).
>
> But we need our own house in order on the CLI. GSoC time!
>
> Phil
>
>
>
>
> On Wed, May 10, 2017 at 7:38 PM, blake watson 
> wrote:
>
>> There is a Java REPL. You could Google that.
>>
>> There's also a some kind of commercial hot/live compiler tool called
>> "JRebel". Haven't tried it (don't code Java).
>>
>> On Wed, May 10, 2017 at 4:29 AM, askoh  wrote:
>>
>>> Kilon:
>>>
>>> This is revelation to me. I am enduring 10 minute turnaround for every
>>> edit I make in *.java, xml, jsp, js files. 4 minute compile and 6 minute
>>> web server update. How can I get that shortened to 10 seconds say? What
>>> links can help? What search terms to google?
>>>
>>> Thanks,
>>> Aik-Siong Koh
>>>
>>> On May 10, 2017, at 3:20 AM, kilon.alios [via Smalltalk] <[hidden email]
>>> > wrote:
>>>
>>> Just to remind people here that all languages with long compile times
>>> can be avoided live coding style through the use of dynamically linked
>>> libraries known as DLLs on windows, shared libraries on linux (*.so) and
>>> macos (*.dylib) . Also Swift in particular comes with a live coding
>>> environment called "Playgrounds" which is also very flexible.
>>>
>>> Haskell do not know if they have something similar to Playgrounds but I
>>> will be surprise if they do not have something at least inferior. All
>>> languages support DLLs including ours.
>>>
>>> Live coding is actually super easy to implement and believe me I was
>>> sceptical about it at first and if I had read this post I am making now I
>>> would call me crazy. But after implementing live coding in python, C and
>>> C++ , now I am a believer. Of course the real question here is if its that
>>> easy why people do not use it . From what 

Re: [Pharo-users] Petri nets and workflow patterns

[Stephane Ducasse]

Norbert

I know petri nets and I was wondering if you were interested in worklow (as
in microworkflow).
because I think that a simple extensible workflow library is missing in
Pharo
Stef

On Wed, May 10, 2017 at 6:13 PM, Norbert Hartl  wrote:

>
> > Am 10.05.2017 um 17:46 schrieb Serge Stinckwich <
> serge.stinckw...@gmail.com>:
> >
> > On Wed, May 10, 2017 at 5:36 PM, Norbert Hartl 
> wrote:
> >> Are there any resources regarding petri nets or control flow…/workflow
> patterns in pharo or smalltalk?
> >
> > We have done some work with one student of Alexandre about BPMN:
> > http://a4bp.com/
> >
> I downloaded the app but it opens with a black screen on my Mac laptop.
>
> > and there is PNTalk also:
> > https://github.com/SergeStinckwich/PNTalk
> >
> Thanks, that is what I was looking for.
>
> > Long time ago I was able to do process mining from logs and generate
> Petri Nets:
> > https://www.youtube.com/watch?v=wdf80t32v-0
>
> That is really close to what I want to play with. Did you ever encounter
> van der Aalst workflow pattern in that context. Do you know any material
> comparing the approaches?
>
> thank you very much,
>
> Norbert
>
>
>

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[p...@highoctane.be]

Or BeanShell

http://www.beanshell.org/

or Groovy
https://zeroturnaround.com/rebellabs/scripting-your-java-application-with-groovy/

or Spring-Shell
https://projects.spring.io/spring-shell/

Example app I am using (and extending) for Hadoop work:
https://github.com/sequenceiq/ambari-shell

When one looks inside a command, this is something easily achievable with
pragmas.

https://github.com/sequenceiq/ambari-shell/blob/master/src/main/java/com/sequenceiq/ambari/shell/commands/BasicCommands.java

There is nothing extraordinary in these pieces of tech ("pas de quoi casser
trois pattes à un canard" in French).

But we need our own house in order on the CLI. GSoC time!

Phil




On Wed, May 10, 2017 at 7:38 PM, blake watson 
wrote:

> There is a Java REPL. You could Google that.
>
> There's also a some kind of commercial hot/live compiler tool called
> "JRebel". Haven't tried it (don't code Java).
>
> On Wed, May 10, 2017 at 4:29 AM, askoh  wrote:
>
>> Kilon:
>>
>> This is revelation to me. I am enduring 10 minute turnaround for every
>> edit I make in *.java, xml, jsp, js files. 4 minute compile and 6 minute
>> web server update. How can I get that shortened to 10 seconds say? What
>> links can help? What search terms to google?
>>
>> Thanks,
>> Aik-Siong Koh
>>
>> On May 10, 2017, at 3:20 AM, kilon.alios [via Smalltalk] <[hidden email]
>> > wrote:
>>
>> Just to remind people here that all languages with long compile times can
>> be avoided live coding style through the use of dynamically linked
>> libraries known as DLLs on windows, shared libraries on linux (*.so) and
>> macos (*.dylib) . Also Swift in particular comes with a live coding
>> environment called "Playgrounds" which is also very flexible.
>>
>> Haskell do not know if they have something similar to Playgrounds but I
>> will be surprise if they do not have something at least inferior. All
>> languages support DLLs including ours.
>>
>> Live coding is actually super easy to implement and believe me I was
>> sceptical about it at first and if I had read this post I am making now I
>> would call me crazy. But after implementing live coding in python, C and
>> C++ , now I am a believer. Of course the real question here is if its that
>> easy why people do not use it . From what I have found out, it has not
>> occurred to them as it did not occur to me.
>>
>> Why C++ coders still endure long compile times when they could test code
>> in an instant through live coding ? Well in games C++ live coding is
>> actually very popular, so some are already aware of the huge advantages of
>> live coding.
>>
>> I think this is an advantage of Pharo , that introduces to live coding, a
>> so simple idea yet so essential without you having to think about it
>> yourself or be already aware of it.
>>
>> With other language you will have to find a tutorial or article that
>> mentions this ability.
>>
>> Another shock for me is how simple it is to implement an image file
>> format for other languages. The shock was that the OS already uses image
>> files like pharo image that calls them "memory mapped files" they are used
>> for sharing memory which in turn is what is used for DLLs. The advantage
>> over the pharo image is that it crash prone, because it is handled by the
>> OS and not the language or the VM. Which means that even if your app
>> crashes the image is still saved and you lose no live data which is not the
>> case with pharo image. The disadvantage is that of course they are not OOP
>> friendly as the pharo image is and they are not language specific as pharo
>> image is.
>>
>> Again I would not have known any of this if I had not been playing with
>> shared memory as an IPC and I also see coders rarely if ever mentioning
>> them.
>>
>>
>>
>> On Wed, May 10, 2017 at 4:09 AM Pierce Ng <[hidden email]
>> > wrote:
>>
>>> On Tue, May 09, 2017 at 06:59:08PM +0200, Stephan Eggermont wrote:
>>> > I don't know. I do know that I can't use something with the
>>> > ridiculous compile times of Haskell or Swift. That just kills flow
>>> > and productivity.
>>>
>>> You could hop onto an office chair and engage your colleague in sword
>>> fighting.
>>> That's a plus! :-)
>>>
>>> Pierce
>>>
>>>
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://forum.world.st/Smalltalkers-will-eventually-win-So-
>> says-this-old-C-programmer-tp4945895p4946404.html
>> To unsubscribe from Smalltalkers will, eventually, win. So says this old
>> C++ programmer., click here.
>> NAML
>> 

[Pharo-users] Glamour Fast List, double click action. Is it supported?

[Juraj Kubelka]

Hi!

Does Glamour Fast List Presentation allow double click action on a item? 

I cannot find anything like that.

Thanks!
Juraj

Re: [Pharo-users] Issue with Pillar

[p...@highoctane.be]

Forget about that way which doesn't work.

Use this: https://github.com/cdlm/docker-texlive

Works nicely and removes 90% of the setup frustration (you'll need latest
docker-ce for this to work).

Phil

On Wed, May 10, 2017 at 5:38 PM, Alexandre Bergel 
wrote:

> Hi!
>
> I am trying to get Pillar working on OS X. I followed the instruction
> given on https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/
> lastSuccessfulBuild/artifact/book-result/PillarChap/Pillar.html
>
> I did:
> curl https://raw.githubusercontent.com/pillar-markup/pillar/
> master/download.sh | bash
> ./pillar archetype welcome
> make book-result/welcome.html
>
> The two first instruction do not seem to cause any trouble. Work as
> expected. The make instruction produces:
> -=-=-=-=
> /tmp/pillar> make book-result/welcome.html
> mkdir -p ./book-result
> find . -type d -path ./book-result -prune -o -wholename "*/figures" -exec
> cp {} --parents -r ./book-result \;
> cp -r support/ ./book-result
> ./pillar export --to=html --outputDirectory=./book-result
> --outputFile=welcome.pillar welcome.pillar
> MessageNotUnderstood: FileReference>>jsonWriteOn:
> FileReference(Object)>>doesNotUnderstand: #jsonWriteOn:
> [ :assoc |
> needComma
> ifTrue: [ aStream nextPut: $, ]
> ifFalse: [ needComma := true ].
> assoc key jsonWriteOn: aStream.
> aStream nextPut: $:.
> assoc value jsonWriteOn: aStream ] in Dictionary>>jsonWriteOn: in Block: [
> :assoc | ...
> [ :each | each ifNotNil: [ aBlock value: each ] ] in
> Dictionary>>associationsDo: in Block: [ :each | each ifNotNil: [ aBlock
> value: each ] ]
> Array(SequenceableCollection)>>do:
> Dictionary>>associationsDo:
> Dictionary>>jsonWriteOn:
> PRExportPhase>>asJson:withConfiguration:
> [ :outStream |
> self
> writeOutput: (self asJson: output withConfiguration: cocoonConfiguration)
> toStream: outStream ] in PRExportPhase>>write:using: in Block: [
> :outStream | ...
> [ aBlock value: stream ] in 
> FileReference(AbstractFileReference)>>writeStreamDo:
> in Block: [ aBlock value: stream ]
> BlockClosure>>ensure:
> FileReference(AbstractFileReference)>>writeStreamDo:
> FileReference(AbstractFileReference)>>pillarWriteDuring:
> PRExportPhase>>outputStreamDuring:
> PRExportPhase>>write:using:
> PRExportPhase>>actionOn:
> PRExportPhase class(PRPhase class)>>executeOn:
> [ :input | self executeOn: input ] in PRExportPhase class(PRPhase
> class)>>buildPipe: in Block: [ :input | self executeOn: input ]
> LPPhase>>executeOn:
> [ :subResult :next | next executeOn: subResult ] in LPPipeline>>executeOn:
> in Block: [ :subResult :next | next executeOn: subResult ]
> [ :each | nextValue := binaryBlock value: nextValue value: each ] in
> OrderedCollection(Collection)>>inject:into: in Block: [ :each | nextValue
> := binaryBlock value: nextValu...etc...
> OrderedCollection>>do:
> OrderedCollection(Collection)>>inject:into:
> LPPipeline>>executeOn:
> PRPillarConfiguration>>export
> [ :exporter | (configuration getConfigurationNamed: exporter) export ] in
> [ configuration defaultExporters
> do: [ :exporter | (configuration getConfigurationNamed: exporter) export ]
> ] in PRExportCommandLineHandler>>export in Block: [ :exporter |
> (configuration getConfigurationNamed...etc...
> Array(SequenceableCollection)>>do:
> [ configuration defaultExporters
> do: [ :exporter | (configuration getConfigurationNamed: exporter) export ]
> ] in PRExportCommandLineHandler>>export in Block: [ configuration
> defaultExporters...
> BlockClosure>>on:do:
> PRExportCommandLineHandler>>export
> PRExportCommandLineHandler>>activate
> make: *** [book-result/welcome.html.json] Error 1
> rm book-result/welcome.html.json
> -=-=-=-=
>
> Any idea what’s wrong?
>
> Cheers,
> Alexandre
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[blake watson]

There is a Java REPL. You could Google that.

There's also a some kind of commercial hot/live compiler tool called
"JRebel". Haven't tried it (don't code Java).

On Wed, May 10, 2017 at 4:29 AM, askoh  wrote:

> Kilon:
>
> This is revelation to me. I am enduring 10 minute turnaround for every
> edit I make in *.java, xml, jsp, js files. 4 minute compile and 6 minute
> web server update. How can I get that shortened to 10 seconds say? What
> links can help? What search terms to google?
>
> Thanks,
> Aik-Siong Koh
>
> On May 10, 2017, at 3:20 AM, kilon.alios [via Smalltalk] <[hidden email]
> > wrote:
>
> Just to remind people here that all languages with long compile times can
> be avoided live coding style through the use of dynamically linked
> libraries known as DLLs on windows, shared libraries on linux (*.so) and
> macos (*.dylib) . Also Swift in particular comes with a live coding
> environment called "Playgrounds" which is also very flexible.
>
> Haskell do not know if they have something similar to Playgrounds but I
> will be surprise if they do not have something at least inferior. All
> languages support DLLs including ours.
>
> Live coding is actually super easy to implement and believe me I was
> sceptical about it at first and if I had read this post I am making now I
> would call me crazy. But after implementing live coding in python, C and
> C++ , now I am a believer. Of course the real question here is if its that
> easy why people do not use it . From what I have found out, it has not
> occurred to them as it did not occur to me.
>
> Why C++ coders still endure long compile times when they could test code
> in an instant through live coding ? Well in games C++ live coding is
> actually very popular, so some are already aware of the huge advantages of
> live coding.
>
> I think this is an advantage of Pharo , that introduces to live coding, a
> so simple idea yet so essential without you having to think about it
> yourself or be already aware of it.
>
> With other language you will have to find a tutorial or article that
> mentions this ability.
>
> Another shock for me is how simple it is to implement an image file format
> for other languages. The shock was that the OS already uses image files
> like pharo image that calls them "memory mapped files" they are used for
> sharing memory which in turn is what is used for DLLs. The advantage over
> the pharo image is that it crash prone, because it is handled by the OS and
> not the language or the VM. Which means that even if your app crashes the
> image is still saved and you lose no live data which is not the case with
> pharo image. The disadvantage is that of course they are not OOP friendly
> as the pharo image is and they are not language specific as pharo image is.
>
> Again I would not have known any of this if I had not been playing with
> shared memory as an IPC and I also see coders rarely if ever mentioning
> them.
>
>
>
> On Wed, May 10, 2017 at 4:09 AM Pierce Ng <[hidden email]
> > wrote:
>
>> On Tue, May 09, 2017 at 06:59:08PM +0200, Stephan Eggermont wrote:
>> > I don't know. I do know that I can't use something with the
>> > ridiculous compile times of Haskell or Swift. That just kills flow
>> > and productivity.
>>
>> You could hop onto an office chair and engage your colleague in sword
>> fighting.
>> That's a plus! :-)
>>
>> Pierce
>>
>>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-
> programmer-tp4945895p4946404.html
> To unsubscribe from Smalltalkers will, eventually, win. So says this old
> C++ programmer., click here.
> NAML
> 
>
>
> --
> View this message in context: Re: Smalltalkers will, eventually, win. So
> says this old C++ programmer.
> 
>
> Sent from the Pharo Smalltalk Users mailing list archive
>  at Nabble.com.
>

Re: [Pharo-users] Intro to git-only Pharo

[Ben Coman]

On Wed, May 10, 2017 at 1:56 PM, Joachim Tuchel  wrote:
> Hi guys,
>
> please forgive me if this mail is a sign of ignorance. I am not a regular
> Pharo user and one of the reasons for this is that I didn't like most of the
> source management tools around Monticello. Coming from an envy background,
> it feels like not being ready for prime time. Of course you guys have been
> proving you can work with these tools quite well, but still I'd be
> interested in using Pharo in a pure git-based environment, as it most
> closely resembles some of the most-beloved features of envy.
>
> Over the years there was a lot of work and discussion on filetree,
> gitfiletree, iceberg, cypress and maybe quite a few other projects that
> sounded promising and interesting. But I must admit I lost track of what was
> really done and how far things went in the last years.
>
> So are there any pointers to info material that I could look at to see what
> the current status of source control in Pharo 5 and Pharo 6 is and/or will
> be soon?
>
> I am mostly interested in these topics:
>
> git only - no monticello meta info any more - possible?

As mentioned in other responses, GitFileTree and Iceberg are operating
without Monticello metadata.
This has been the case for a while but personally, even to I love to
use git for C code, I just haven't managed to make the leap for
image-side Pharo.  Monticello was "good enough".  Probably a lot of
people are the same.  Now with the coming Pharo 7,  Iceberg/git will
be the only game in town for "pharo-core contributions".  Everyone
will be forced to use Iceberg (and personally I welcome this) and
there'll be many more eyeballs to polish off any rough edges of the
tools and workflow.  So *now* in Pharo 7 is an ideal time to start
paying attention and to help identify any gaps in requirements for
Pharo git tools and workflow.

cheers -ben

> tools like merge/diff, committing from within the image
> dependencies within my own project as well as dependencies on external code
> in - possibly multiple - external repositories
> what is the current "most official" source repository for open source code?
> best practices for managing complex projects and keeping old versions
> reproducible at any time
> tutorial for git newbies in a Pharo context? (Like, how do I start with a
> new packege - create folder first and do git init, or start in the image and
> push into repo later? as I said: beginners' stuff)
>
> Thanks for pointers and help
>
>
> Joachim
>
>

Re: [Pharo-users] Remote Debugger bugs ?

[Denis Kudriashov]

2017-05-10 11:16 GMT+02:00 Steven Costiou :

> In the end i will embed the remote image in a raspberry pi and access it
> remotely, so the ui will (absolutely) not be needed


I am currently working on RPI support. I will present it next week.
If you want to try:

Metacello new
smalltalkhubUser: 'Pharo' project: 'IoT';
configuration: 'IoT';
version: #stable;
load: 'RemoteToolsServer'.

Then from playground evaluate:

lib := remotePharo evaluate: [ WiringPiLibrary uniqueInstance].
board := RpiBoardBRev1 driver: (RpiWiringPiDriver lib: lib).

board inspect

It requires wiringPi external library which I think should be installed by
default.
Anyway I will publish it next week with more details and demos.

Re: [Pharo-users] Petri nets and workflow patterns

[Norbert Hartl]

> Am 10.05.2017 um 17:46 schrieb Serge Stinckwich :
> 
> On Wed, May 10, 2017 at 5:36 PM, Norbert Hartl  wrote:
>> Are there any resources regarding petri nets or control flow…/workflow 
>> patterns in pharo or smalltalk?
> 
> We have done some work with one student of Alexandre about BPMN:
> http://a4bp.com/
> 
I downloaded the app but it opens with a black screen on my Mac laptop.

> and there is PNTalk also:
> https://github.com/SergeStinckwich/PNTalk
> 
Thanks, that is what I was looking for. 

> Long time ago I was able to do process mining from logs and generate Petri 
> Nets:
> https://www.youtube.com/watch?v=wdf80t32v-0

That is really close to what I want to play with. Did you ever encounter van 
der Aalst workflow pattern in that context. Do you know any material comparing 
the approaches?

thank you very much,

Norbert

Re: [Pharo-users] Petri nets and workflow patterns

[Serge Stinckwich]

On Wed, May 10, 2017 at 5:36 PM, Norbert Hartl  wrote:
> Are there any resources regarding petri nets or control flow…/workflow 
> patterns in pharo or smalltalk?

We have done some work with one student of Alexandre about BPMN:
http://a4bp.com/

and there is PNTalk also:
https://github.com/SergeStinckwich/PNTalk

Long time ago I was able to do process mining from logs and generate Petri Nets:
https://www.youtube.com/watch?v=wdf80t32v-0


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

[Pharo-users] Issue with Pillar

[Alexandre Bergel]

Hi!

I am trying to get Pillar working on OS X. I followed the instruction given on 
https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/PillarChap/Pillar.html

I did:
curl https://raw.githubusercontent.com/pillar-markup/pillar/master/download.sh 
| bash
./pillar archetype welcome
make book-result/welcome.html

The two first instruction do not seem to cause any trouble. Work as expected. 
The make instruction produces:
-=-=-=-=
/tmp/pillar> make book-result/welcome.html
mkdir -p ./book-result
find . -type d -path ./book-result -prune -o -wholename "*/figures" -exec cp {} 
--parents -r ./book-result \;
cp -r support/ ./book-result
./pillar export --to=html --outputDirectory=./book-result 
--outputFile=welcome.pillar welcome.pillar
MessageNotUnderstood: FileReference>>jsonWriteOn:
FileReference(Object)>>doesNotUnderstand: #jsonWriteOn:
[ :assoc | 
needComma
ifTrue: [ aStream nextPut: $, ]
ifFalse: [ needComma := true ].
assoc key jsonWriteOn: aStream.
aStream nextPut: $:.
assoc value jsonWriteOn: aStream ] in Dictionary>>jsonWriteOn: in Block: [ 
:assoc | ...
[ :each | each ifNotNil: [ aBlock value: each ] ] in 
Dictionary>>associationsDo: in Block: [ :each | each ifNotNil: [ aBlock value: 
each ] ]
Array(SequenceableCollection)>>do:
Dictionary>>associationsDo:
Dictionary>>jsonWriteOn:
PRExportPhase>>asJson:withConfiguration:
[ :outStream | 
self
writeOutput: (self asJson: output withConfiguration: 
cocoonConfiguration)
toStream: outStream ] in PRExportPhase>>write:using: in Block: [ 
:outStream | ...
[ aBlock value: stream ] in 
FileReference(AbstractFileReference)>>writeStreamDo: in Block: [ aBlock value: 
stream ]
BlockClosure>>ensure:
FileReference(AbstractFileReference)>>writeStreamDo:
FileReference(AbstractFileReference)>>pillarWriteDuring:
PRExportPhase>>outputStreamDuring:
PRExportPhase>>write:using:
PRExportPhase>>actionOn:
PRExportPhase class(PRPhase class)>>executeOn:
[ :input | self executeOn: input ] in PRExportPhase class(PRPhase 
class)>>buildPipe: in Block: [ :input | self executeOn: input ]
LPPhase>>executeOn:
[ :subResult :next | next executeOn: subResult ] in LPPipeline>>executeOn: in 
Block: [ :subResult :next | next executeOn: subResult ]
[ :each | nextValue := binaryBlock value: nextValue value: each ] in 
OrderedCollection(Collection)>>inject:into: in Block: [ :each | nextValue := 
binaryBlock value: nextValu...etc...
OrderedCollection>>do:
OrderedCollection(Collection)>>inject:into:
LPPipeline>>executeOn:
PRPillarConfiguration>>export
[ :exporter | (configuration getConfigurationNamed: exporter) export ] in [ 
configuration defaultExporters
do: [ :exporter | (configuration getConfigurationNamed: exporter) 
export ] ] in PRExportCommandLineHandler>>export in Block: [ :exporter | 
(configuration getConfigurationNamed...etc...
Array(SequenceableCollection)>>do:
[ configuration defaultExporters
do: [ :exporter | (configuration getConfigurationNamed: exporter) 
export ] ] in PRExportCommandLineHandler>>export in Block: [ configuration 
defaultExporters...
BlockClosure>>on:do:
PRExportCommandLineHandler>>export
PRExportCommandLineHandler>>activate
make: *** [book-result/welcome.html.json] Error 1
rm book-result/welcome.html.json
-=-=-=-=

Any idea what’s wrong?

Cheers,
Alexandre

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

[Pharo-users] Petri nets and workflow patterns

[Norbert Hartl]

Are there any resources regarding petri nets or control flow…/workflow patterns 
in pharo or smalltalk?

thanks,

Norbert

Re: [Pharo-users] Working with remote debugger: how to debug something happening in the remote image ?

[Steven Costiou]

It works :) 

Thanks :) 

Le 2017-05-10 14:22, Denis Kudriashov a écrit :

> 2017-05-10 13:49 GMT+02:00 Steven Costiou :
> 
>> Then i do openPlayground and TestClass new inspect ->  i got an inspector on 
>> the proxy object. If i do "self test inspect" inside it, i got the same 
>> debugger opening, telling me the error but with the "proxy stack" and not 
>> the test method where the problem is. Basically it seems that everything i 
>> try to remotely execute from the local image falls into this case. I did not 
>> try to start a process when starting the remote image so maybe this works. 
>> My question is, is there a way to remotely execute (user) code that will 
>> open the debugger on the "right" stack ? (or did i do something wrong ?)
> 
> Currently to get real debugger from playground script you need evaluate fork 
> over expression. For example following code in remote playground: 
> 
>> [1/0] fork
> 
> it will open debugger on remote process. But if you just execute "1/0" then 
> you will got local debugger with "RemoteException~" title without remote 
> stack. 
> 
> It works like that because remote request itself handles failures and 
> transfers them as result back to local image. It is suitable strategy for 
> many cases and it is most simple and safe to implement. But now there is no 
> way how to setup another strategy to open remote debugger.  
> So to escape internal communication handler you need fork evaluated 
> expression. When remote image produces unhandled error it will spawn debugger 
> which will be connected remote debugger in our case. That's why #fork is 
> needed: to ensure unhandled failures.  
> 
> I not hide this specifics inside remote playground because during debugging 
> of all this remote tools it is suitable to just see communication failure 
> instead of remote debugger. When remote debugger is opening it also 
> communicates with remote side and if communication logic is broken it leads 
> to infinite recursion and frozen image. 
> In future I will make this behaviour natural (like in local playground) but 
> right now my scenario is: 
> - evaluate desired code in playground. 
> - if It fails ( RemoteException with description of actual failure) then wrap 
> it with fork and got remote debugger.

  

Re: [Pharo-users] Working with remote debugger: how to debug something happening in the remote image ?

[Denis Kudriashov]

2017-05-10 13:49 GMT+02:00 Steven Costiou :

> Then i do openPlayground and TestClass new inspect −>  i got an inspector
> on the proxy object. If i do "self test inspect" inside it, i got the same
> debugger opening, telling me the error but with the "proxy stack" and not
> the test method where the problem is. Basically it seems that everything i
> try to remotely execute from the local image falls into this case. I did
> not try to start a process when starting the remote image so maybe this
> works. My question is, is there a way to remotely execute (user) code that
> will open the debugger on the "right" stack ? (or did i do something wrong
> ?)


Currently to get real debugger from playground script you need evaluate
fork over expression. For example following code in remote playground:

[1/0] fork

it will open debugger on remote process. But if you just execute "1/0" then
you will got local debugger with "RemoteException~" title without remote
stack.

It works like that because remote request itself handles failures and
transfers them as result back to local image. It is suitable strategy for
many cases and it is most simple and safe to implement. But now there is no
way how to setup another strategy to open remote debugger.
So to escape internal communication handler you need fork evaluated
expression. When remote image produces unhandled error it will spawn
debugger which will be connected remote debugger in our case. That's why
#fork is needed: to ensure unhandled failures.

I not hide this specifics inside remote playground because during debugging
of all this remote tools it is suitable to just see communication failure
instead of remote debugger. When remote debugger is opening it also
communicates with remote side and if communication logic is broken it leads
to infinite recursion and frozen image.
In future I will make this behaviour natural (like in local playground) but
right now my scenario is:
- evaluate desired code in playground.
- if It fails ( RemoteException with description of actual failure) then
wrap it with fork and got remote debugger.

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[nacho]

Kilion,
In Haskell (a language that I love, just as Smalltalk) you have the REPL.
The workflow is, while you are working on the project, you periodically load
that file into the REPL and check. After that you compile. Haskell works
with a strong type inference feature, however most Haskellers will say that
the best practice is to annotate all functions. Also if you are on macOS you
have: http://haskellformac.com/ which is awesome, really a great piece of
software. There was even a project called Kronos that was essentially the
same as IPython but with a Haskell kernel I don't know the status of that
project as of today, I really never used it.
just my 2c
best
Nacho




-
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
--
View this message in context: 
http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-programmer-tp4945895p4946433.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Working with remote debugger: how to debug something happening in the remote image ?

[Steven Costiou]

> If you want to fight with it then my first idea would be to find how method 
> AST is built in sugs menu. Then try to look at senders of 
> #astForStylingInCalypso which was implemented to support styling of remote 
> methods. Try to use it somehow for sugs menu too. 
> Maybe it will fix everything

Yes, i will have a look - i need the right click menu to properly work
so i need that to be fixed. The workaround i used was to just disable
suggestions by returning empty suggs collections, but i will see if i
can do something better. 

Thanks Denis. 

Re: [Pharo-users] Working with remote debugger: how to debug something happening in the remote image ?

[Steven Costiou]

Ok, so there is this problem. I just wanted to try the debugger on it. 

But i have the same problem with my own user code. For example i did
open a remote browser, create a test package with a class TestClass and
a method test>>^'1', 0. 

Then i do openPlayground and TestClass new inspect ->  i got an
inspector on the proxy object. If i do "self test inspect" inside it, i
got the same debugger opening, telling me the error but with the "proxy
stack" and not the test method where the problem is. Basically it seems
that everything i try to remotely execute from the local image falls
into this case. I did not try to start a process when starting the
remote image so maybe this works. My question is, is there a way to
remotely execute (user) code that will open the debugger on the "right"
stack ? (or did i do something wrong ?) 

Le 2017-05-10 13:21, Denis Kudriashov a écrit :

> Problem that right now many thinks in browser are not supported in remote 
> scenario: most of refactorings are not work and as you see suggestion menu 
> not works too. 
> 
> It is local tools problem, the way how local tools communicate with remote 
> environment to perform particular operations. When you try debug such 
> operations local debugger stops at the place of remote request. Distributed 
> debugger (which shows multiple process stacks) is not done. But it will not 
> help here. 
> 
> Generally there are many cases when transparent remoting is not working. And 
> to fix concrete scenario proper model is needed which is taken into account 
> that it can be distributed across network borders. 
> In this case suggestion menu operates with local AST-nodes of remote method 
> which is required non trivial logic to be handled properly. 
> 
> Anyway these features will be supported in future.. 
> 
> 2017-05-10 11:28 GMT+02:00 Steven Costiou :
> 
>> While configuring my local and remote images to work with the remote 
>> debugger, there was a bug with the menu in the remote browser. So i wanted 
>> to try the debugger and figure out what was the problem using it, but i do 
>> not understand how to proceed. When the debugger opens, all i see is the 
>> fact that there was a remote problem, and that the proxy was unable to 
>> return a proper value.
>> 
>> I used a local image connected with a headless remote image. To reproduce 
>> the bug, go for example in ByteString >> at:put:, right click after the 
>> first dot and click "debug". See suggs-menu-bug.png. 
>> 
>> When doing that i get debug-win.png and suggs-debug.png and as you can see i 
>> just know there was an error and what it was but i don't have an open 
>> debugger as i would normally expect in Pharo. How can i see the real problem 
>> occuring in the remote image ? How can i remotely fix this considering that 
>> my remote image is headless and it seems to be a problem tied to the remote 
>> thing, because locally it doesn't happen ? (or maybe it is a Calypso problem 
>> but anyway i cannot debug it...) 
>> 
>> Steven.

  

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[askoh]

Kilon:

This is revelation to me. I am enduring 10 minute turnaround for every edit I 
make in *.java, xml, jsp, js files. 4 minute compile and 6 minute web server 
update. How can I get that shortened to 10 seconds say? What links can help? 
What search terms to google?

Thanks,
Aik-Siong Koh

> On May 10, 2017, at 3:20 AM, kilon.alios [via Smalltalk] 
>  wrote:
> 
> Just to remind people here that all languages with long compile times can be 
> avoided live coding style through the use of dynamically linked libraries 
> known as DLLs on windows, shared libraries on linux (*.so) and macos 
> (*.dylib) . Also Swift in particular comes with a live coding environment 
> called "Playgrounds" which is also very flexible. 
> 
> Haskell do not know if they have something similar to Playgrounds but I will 
> be surprise if they do not have something at least inferior. All languages 
> support DLLs including ours. 
> 
> Live coding is actually super easy to implement and believe me I was 
> sceptical about it at first and if I had read this post I am making now I 
> would call me crazy. But after implementing live coding in python, C and C++ 
> , now I am a believer. Of course the real question here is if its that easy 
> why people do not use it . From what I have found out, it has not occurred to 
> them as it did not occur to me. 
> 
> Why C++ coders still endure long compile times when they could test code in 
> an instant through live coding ? Well in games C++ live coding is actually 
> very popular, so some are already aware of the huge advantages of live 
> coding. 
> 
> I think this is an advantage of Pharo , that introduces to live coding, a so 
> simple idea yet so essential without you having to think about it yourself or 
> be already aware of it.
> 
> With other language you will have to find a tutorial or article that mentions 
> this ability.  
> 
> Another shock for me is how simple it is to implement an image file format 
> for other languages. The shock was that the OS already uses image files like 
> pharo image that calls them "memory mapped files" they are used for sharing 
> memory which in turn is what is used for DLLs. The advantage over the pharo 
> image is that it crash prone, because it is handled by the OS and not the 
> language or the VM. Which means that even if your app crashes the image is 
> still saved and you lose no live data which is not the case with pharo image. 
> The disadvantage is that of course they are not OOP friendly as the pharo 
> image is and they are not language specific as pharo image is. 
> 
> Again I would not have known any of this if I had not been playing with 
> shared memory as an IPC and I also see coders rarely if ever mentioning them. 
> 
> 
> 
>> On Wed, May 10, 2017 at 4:09 AM Pierce Ng <[hidden email]> wrote:
>> On Tue, May 09, 2017 at 06:59:08PM +0200, Stephan Eggermont wrote:
>> > I don't know. I do know that I can't use something with the
>> > ridiculous compile times of Haskell or Swift. That just kills flow
>> > and productivity.
>> 
>> You could hop onto an office chair and engage your colleague in sword 
>> fighting.
>> That's a plus! :-)
>> 
>> Pierce
>> 
> 
> 
> If you reply to this email, your message will be added to the discussion 
> below:
> http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-programmer-tp4945895p4946404.html
> To unsubscribe from Smalltalkers will, eventually, win. So says this old C++ 
> programmer., click here.
> NAML




--
View this message in context: 
http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-programmer-tp4945895p4946427.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] Working with remote debugger: how to debug something happening in the remote image ?

[Denis Kudriashov]

2017-05-10 11:28 GMT+02:00 Steven Costiou :

> How can i remotely fix this considering that my remote image is headless
> and it seems to be a problem tied to the remote thing, because locally it
> doesn't happen ? (or maybe it is a Calypso problem but anyway i cannot
> debug it...)


If you want to fight with it then my first idea would be to find how method
AST is built in sugs menu. Then try to look at senders of
#astForStylingInCalypso which was implemented to support styling of remote
methods. Try to use it somehow for sugs menu too.
Maybe it will fix everything

Re: [Pharo-users] Working with remote debugger: how to debug something happening in the remote image ?

[Denis Kudriashov]

Problem that right now many thinks in browser are not supported in remote
scenario: most of refactorings are not work and as you see suggestion menu
not works too.

It is local tools problem, the way how local tools communicate with remote
environment to perform particular operations. When you try debug such
operations local debugger stops at the place of remote request. Distributed
debugger (which shows multiple process stacks) is not done. But it will not
help here.

Generally there are many cases when transparent remoting is not working.
And to fix concrete scenario proper model is needed which is taken into
account that it can be distributed across network borders.
In this case suggestion menu operates with local AST-nodes of remote method
which is required non trivial logic to be handled properly.

Anyway these features will be supported in future..

2017-05-10 11:28 GMT+02:00 Steven Costiou :

> While configuring my local and remote images to work with the remote
> debugger, there was a bug with the menu in the remote browser. So i wanted
> to try the debugger and figure out what was the problem using it, but i do
> not understand how to proceed. When the debugger opens, all i see is the
> fact that there was a remote problem, and that the proxy was unable to
> return a proper value.
>
> I used a local image connected with a headless remote image. To reproduce
> the bug, go for example in ByteString >> at:put:, right click after the
> first dot and click "debug". See suggs-menu-bug.png.
>
> When doing that i get debug-win.png and suggs-debug.png and as you can see
> i just know there was an error and what it was but i don't have an open
> debugger as i would normally expect in Pharo. How can i see the real
> problem occuring in the remote image ? How can i remotely fix this
> considering that my remote image is headless and it seems to be a problem
> tied to the remote thing, because locally it doesn't happen ? (or maybe it
> is a Calypso problem but anyway i cannot debug it...)
>
>
>
> Steven.
>

Re: [Pharo-users] [Pharo-dev] [ann] bloc & cairo+morphic

[Torsten Bergmann]

When I try to download on OSX the #dev version as outlined on Tudors blog
the download of the Moz2D lib for OSX fails: code tries to #download in 
class MozLibraryMacInstaller from 

http://syrel.ch/download.php?url=https://dl.bintray.com/syrel/Moz2D/osx/development/i386/libMoz2D.dylib

which just hangs as it is not receiving a response.

Any comments?

Thx
T.
   

> Gesendet: Dienstag, 09. Mai 2017 um 14:04 Uhr
> Von: "Alexandre Bergel" 
> An: "Pharo Development List" 
> Cc: "Moose-related development" , "Any question 
> about pharo is welcome" 
> Betreff: Re: [Pharo-dev] [ann] bloc & cairo+morphic
>
> This is amazing! I gave a try an it really looks great!
> 
> Alexandre
> 
> 
> > On May 8, 2017, at 6:00 PM, Tudor Girba  wrote:
> > 
> > Hi,
> > 
> > We are happy to announce that based on the work of Glenn, Alex extended 
> > Bloc (Sparta) to work directly in the Morphic world using Cairo as a 
> > backend.
> > 
> > Cairo is less powerful than Moz2D (see the screenshot below for an 
> > example), but the implementation addresses a concern that the community 
> > raised regarding a perceived increased liability due to the dependency to 
> > Moz2D. Essentially this means that Bloc can be treated as another graphical 
> > library that can coexist with Morphic without requiring any external VM 
> > plugin.
> > 
> > 
> > 
> > I would also like to point out that adding a new backend and host was 
> > possible because of the many iterations (including throwing away whole 
> > implementations) that Alex and Glenn went through. I think they did an 
> > amazing job.
> > 
> > You can find a bit more details about Bloc here:
> > http://www.humane-assessment.com/blog/bloc-flexible-backends-hosts/
> > 
> > Another issue raised regarding Bloc was that of the engineering effort 
> > required to make it a reality. That is why I would also like to announce 
> > that Alex joined feenk.com where he is primarily working on the graphical 
> > stack for Pharo.
> > 
> > Cheers,
> > Doru
> > 
> > 
> > --
> > www.tudorgirba.com
> > www.feenk.com
> > 
> > "To lead is not to demand things, it is to make them happen."
> > 
> > 
> > 
> > 
> 
> 
> 

Re: [Pharo-users] Working with remote debugger: how to debug something happening in the remote image ?

[Steven Costiou]

Le 2017-05-10 11:28, Steven Costiou a écrit :

> While configuring my local and remote images to work with the remote 
> debugger, there was a bug with the menu in the remote browser. So i wanted to 
> try the debugger and figure out what was the problem using it, but i do not 
> understand how to proceed. When the debugger opens, all i see is the fact 
> that there was a remote problem, and that the proxy was unable to return a 
> proper value.
> 
> I used a local image connected with a headless remote image. To reproduce the 
> bug, go for example in ByteString >> at:put:, right click after the first dot 
> and click "debug". See suggs-menu-bug.png. 
> 
> When doing that i get debug-win.png and suggs-debug.png and as you can see i 
> just know there was an error and what it was but i don't have an open 
> debugger as i would normally expect in Pharo. How can i see the real problem 
> occuring in the remote image ? How can i remotely fix this considering that 
> my remote image is headless and it seems to be a problem tied to the remote 
> thing, because locally it doesn't happen ? (or maybe it is a Calypso problem 
> but anyway i cannot debug it...) 
> 
> Steven.

Hem, i forgot to say that i did that in a remote browser after sending
openBrowser to a PRRemotePharo 

Re: [Pharo-users] Remote Debugger bugs ?

[Steven Costiou]

> I found the issue. Debugging remote UI process is not supported well. When 
> you close debugger remote UI process is terminated which makes remote image 
> unresponsive. 
> But it is not completely frozen. You can spawn new UI process remotely: 
> 
>> remotePharo evaluate: [ UIManager default spawnNewProcess  ].
> 
> Or from remote playground just evaluate it directly: 
> 
>> UIManager default spawnNewProcess

Thanks, it works :) 

> I will think how to support it properly.  
> I wondering do you just play or you have real requirements for this scenario? 
> (I not thought it is important)

No i am playing with it while configuring my images. It's easier to test
things on both images with the uis when doing that. In the end i will
embed the remote image in a raspberry pi and access it remotely, so the
ui will (absolutely) not be needed. However, it is conceivable to have a
desktop app that i want to connect to for example if a remote user
experiences problems and i want to query things or to ask the user to
perform operations. 
If i do such queries i can make mistakes and i would have to
proceed/abandon/close debug windows. In this case both will need a ui. 

Re: [Pharo-users] Intro to git-only Pharo

[Norbert Hartl]

Hi Joachim,

I think your timing is quite good. We had some changes in the last years and it 
is getting better now. 
Before we had only monticello. Monticello is a zip container that contains a 
version number in the filename and prior version pointer inside the repository. 
Regarding dependencies there was nothing that was used widely. Then Metacello 
appeared and solved the problem by providing dependency management and 
versioning of dependencies. Dependency management works good, the integrated 
versioning has issues. Especially when you look at a system like git you can 
see that versioning is solved there. Filetree is needed because git and other 
vcs systems are file based so you need to layout your code in files (how 
quaint!)
To make a long story short: The best thing to use is git with Metacello 
Baselines. Filetree is used to store code. Versioning you do with git tags that 
can be used in Baselines. Now we have a decent UI (iceberg) that supports the 
most needed workflow items. 
We have a UI for the dependency management as well (versionner) but it sadly 
targets ConfigurationOfs and not BaselineOfs. That needs to be changed.

my 2 cents,

Norbert

> Am 10.05.2017 um 07:56 schrieb Joachim Tuchel :
> 
> Hi guys,
> 
> please forgive me if this mail is a sign of ignorance. I am not a regular 
> Pharo user and one of the reasons for this is that I didn't like most of the 
> source management tools around Monticello. Coming from an envy background, it 
> feels like not being ready for prime time. Of course you guys have been 
> proving you can work with these tools quite well, but still I'd be interested 
> in using Pharo in a pure git-based environment, as it most closely resembles 
> some of the most-beloved features of envy.
> 
> Over the years there was a lot of work and discussion on filetree, 
> gitfiletree, iceberg, cypress and maybe quite a few other projects that 
> sounded promising and interesting. But I must admit I lost track of what was 
> really done and how far things went in the last years.
> 
> So are there any pointers to info material that I could look at to see what 
> the current status of source control in Pharo 5 and Pharo 6 is and/or will be 
> soon?
> 
> I am mostly interested in these topics:
> 
> git only - no monticello meta info any more - possible?
> tools like merge/diff, committing from within the image
> dependencies within my own project as well as dependencies on external code 
> in - possibly multiple - external repositories
> what is the current "most official" source repository for open source code?
> best practices for managing complex projects and keeping old versions 
> reproducible at any time
> tutorial for git newbies in a Pharo context? (Like, how do I start with a new 
> packege - create folder first and do git init, or start in the image and push 
> into repo later? as I said: beginners' stuff)
> Thanks for pointers and help
> 
> Joachim
> 

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

[Dimitris Chloupis]

Just to remind people here that all languages with long compile times can
be avoided live coding style through the use of dynamically linked
libraries known as DLLs on windows, shared libraries on linux (*.so) and
macos (*.dylib) . Also Swift in particular comes with a live coding
environment called "Playgrounds" which is also very flexible.

Haskell do not know if they have something similar to Playgrounds but I
will be surprise if they do not have something at least inferior. All
languages support DLLs including ours.

Live coding is actually super easy to implement and believe me I was
sceptical about it at first and if I had read this post I am making now I
would call me crazy. But after implementing live coding in python, C and
C++ , now I am a believer. Of course the real question here is if its that
easy why people do not use it . From what I have found out, it has not
occurred to them as it did not occur to me.

Why C++ coders still endure long compile times when they could test code in
an instant through live coding ? Well in games C++ live coding is actually
very popular, so some are already aware of the huge advantages of live
coding.

I think this is an advantage of Pharo , that introduces to live coding, a
so simple idea yet so essential without you having to think about it
yourself or be already aware of it.

With other language you will have to find a tutorial or article that
mentions this ability.

Another shock for me is how simple it is to implement an image file format
for other languages. The shock was that the OS already uses image files
like pharo image that calls them "memory mapped files" they are used for
sharing memory which in turn is what is used for DLLs. The advantage over
the pharo image is that it crash prone, because it is handled by the OS and
not the language or the VM. Which means that even if your app crashes the
image is still saved and you lose no live data which is not the case with
pharo image. The disadvantage is that of course they are not OOP friendly
as the pharo image is and they are not language specific as pharo image is.

Again I would not have known any of this if I had not been playing with
shared memory as an IPC and I also see coders rarely if ever mentioning
them.



On Wed, May 10, 2017 at 4:09 AM Pierce Ng  wrote:

> On Tue, May 09, 2017 at 06:59:08PM +0200, Stephan Eggermont wrote:
> > I don't know. I do know that I can't use something with the
> > ridiculous compile times of Haskell or Swift. That just kills flow
> > and productivity.
>
> You could hop onto an office chair and engage your colleague in sword
> fighting.
> That's a plus! :-)
>
> Pierce
>
>

Re: [Pharo-users] Intro to git-only Pharo

[jtuc...@objektfabrik.de]

Peter,

thanks for your view and links. Helps me sort things out and find what's 
remained and keeps being relevant ;-)


Joachim

Am 10.05.17 um 10:08 schrieb Peter Uhnak:

Hi,

this is my (=not canonical) perspective

On Wed, May 10, 2017 at 07:56:19AM +0200, Joachim Tuchel wrote:

Hi guys,

please forgive me if this mail is a sign of ignorance. I am not a
regular Pharo user and one of the reasons for this is that I didn't
like most of the source management tools around Monticello. Coming
from an envy background, it feels like not being ready for prime
time. Of course you guys have been proving you can work with these
tools quite well, but still I'd be interested in using Pharo in a
pure git-based environment, as it most closely resembles some of the
most-beloved features of envy.

Over the years there was a lot of work and discussion on filetree,
gitfiletree, iceberg, cypress and maybe quite a few other projects
that sounded promising and interesting. But I must admit I lost
track of what was really done and how far things went in the last
years.

So are there any pointers to info material that I could look at to
see what the current status of source control in Pharo 5 and Pharo 6
is and/or will be soon?

I am mostly interested in these topics:

  * git only - no monticello meta info any more - possible?

first of all -- filetree is an export format which stores Pharo code in an 
organized fashion on disk... a folder for every package, folder for every 
class, file for every method... e.g. 
https://github.com/peteruhnak/pharo-changes-builder/tree/master/repository/ChangesBuilder.package/CBClass.class/instance
this format makes it easier for git to manage the code.

There however two variants of filetree... one containing metacello metadata, 
e.g. the red here 
https://github.com/peteruhnak/IconFactory/commit/729da03653d527bd6ca34e0a512b1c1c634fd32e
 - which caused a lot of pains during merging (because you are almost 
guaranteed a merge conflict)... so a new variant emerged which doesn't use this 
metadata and instead determines it directly from git versioning.

neither GitFileTree (which is a filetree that performs git commits on the 
background) nor Iceberg use monticello metadata.

GFT is still managed via Monticello tools, but the metadata is derived from git 
commits. This is what I've been using for ~two years until recently (now I've 
switched to Iceberg).
I wrote a guide about GFT some time ago 
https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-and-github-with-pharo/

Iceberg uses the same filetree format as GFT (so they are compatible), but the 
tooling inside Pharo has changed. Now there is dedicated iceberg interface for 
managing git repositories and projects. Although Iceberg is not in stable yet, so 
it breaks from time to time, but when it works I am really happy with it. (Thanks 
Esteban & Nico!).



  * tools like merge/diff, committing from within the image

Committing from within the image is handled with both GFT and Iceberg; merging 
is not yet. (And of course you see diff when committing/comparing versions)


  * dependencies within my own project as well as dependencies on
external code in - possibly multiple - external repositories

With git came also the switch from ConfigurationOf to BaselineOf, which 
somewhat simplified version and dependency management. The Baseline is no 
longer filled with methods for each version, as this is handled by git.



  * what is the current "most official" source repository for open
source code?

for Monticello naturally SmalltalkHub/ss3; for git GitHub, however you are not 
restricted from other git sites (gitlab, bitbucket, your own server, ...)


  * best practices for managing complex projects and keeping old
versions reproducible at any time

well, this is quite general question... I'd say semver.org is a good start, 
however most people depend on #stable and #development, which are not actually 
versions, so reproducibility is not possible... but there is work being done 
iirc regarding better dependency management (Cargo iirc)



  * tutorial for git newbies in a Pharo context? (Like, how do I start
with a new packege - create folder first and do git init, or start
in the image and push into repo later? as I said: beginners' stuff)

Chapter 8 of Pharo by example, 
https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-and-github-with-pharo/
 and possibly other resources.

Peter





--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Re: [Pharo-users] Intro to git-only Pharo

[Peter Uhnak]

Hi,

this is my (=not canonical) perspective

On Wed, May 10, 2017 at 07:56:19AM +0200, Joachim Tuchel wrote:
> Hi guys,
> 
> please forgive me if this mail is a sign of ignorance. I am not a
> regular Pharo user and one of the reasons for this is that I didn't
> like most of the source management tools around Monticello. Coming
> from an envy background, it feels like not being ready for prime
> time. Of course you guys have been proving you can work with these
> tools quite well, but still I'd be interested in using Pharo in a
> pure git-based environment, as it most closely resembles some of the
> most-beloved features of envy.
> 
> Over the years there was a lot of work and discussion on filetree,
> gitfiletree, iceberg, cypress and maybe quite a few other projects
> that sounded promising and interesting. But I must admit I lost
> track of what was really done and how far things went in the last
> years.
> 
> So are there any pointers to info material that I could look at to
> see what the current status of source control in Pharo 5 and Pharo 6
> is and/or will be soon?
> 
> I am mostly interested in these topics:
> 
>  * git only - no monticello meta info any more - possible?

first of all -- filetree is an export format which stores Pharo code in an 
organized fashion on disk... a folder for every package, folder for every 
class, file for every method... e.g. 
https://github.com/peteruhnak/pharo-changes-builder/tree/master/repository/ChangesBuilder.package/CBClass.class/instance
this format makes it easier for git to manage the code.

There however two variants of filetree... one containing metacello metadata, 
e.g. the red here 
https://github.com/peteruhnak/IconFactory/commit/729da03653d527bd6ca34e0a512b1c1c634fd32e
 - which caused a lot of pains during merging (because you are almost 
guaranteed a merge conflict)... so a new variant emerged which doesn't use this 
metadata and instead determines it directly from git versioning.

neither GitFileTree (which is a filetree that performs git commits on the 
background) nor Iceberg use monticello metadata.

GFT is still managed via Monticello tools, but the metadata is derived from git 
commits. This is what I've been using for ~two years until recently (now I've 
switched to Iceberg).
I wrote a guide about GFT some time ago 
https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-and-github-with-pharo/

Iceberg uses the same filetree format as GFT (so they are compatible), but the 
tooling inside Pharo has changed. Now there is dedicated iceberg interface for 
managing git repositories and projects. Although Iceberg is not in stable yet, 
so it breaks from time to time, but when it works I am really happy with it. 
(Thanks Esteban & Nico!).


>  * tools like merge/diff, committing from within the image

Committing from within the image is handled with both GFT and Iceberg; merging 
is not yet. (And of course you see diff when committing/comparing versions)

>  * dependencies within my own project as well as dependencies on
>external code in - possibly multiple - external repositories

With git came also the switch from ConfigurationOf to BaselineOf, which 
somewhat simplified version and dependency management. The Baseline is no 
longer filled with methods for each version, as this is handled by git.


>  * what is the current "most official" source repository for open
>source code?

for Monticello naturally SmalltalkHub/ss3; for git GitHub, however you are not 
restricted from other git sites (gitlab, bitbucket, your own server, ...)

>  * best practices for managing complex projects and keeping old
>versions reproducible at any time

well, this is quite general question... I'd say semver.org is a good start, 
however most people depend on #stable and #development, which are not actually 
versions, so reproducibility is not possible... but there is work being done 
iirc regarding better dependency management (Cargo iirc)


>  * tutorial for git newbies in a Pharo context? (Like, how do I start
>with a new packege - create folder first and do git init, or start
>in the image and push into repo later? as I said: beginners' stuff)

Chapter 8 of Pharo by example, 
https://www.peteruhnak.com/blog/2016/07/25/how-to-use-git-and-github-with-pharo/
 and possibly other resources.

Peter

Re: [Pharo-users] Intro to git-only Pharo

[jtuc...@objektfabrik.de]

Stef,

thanks for answering.

Am 10.05.17 um 08:59 schrieb Stephane Ducasse:

Hi joachim

There is a distinction between managing projects and pharo. Pharo 60 
is managed with Monticello.

Pharo 70 will not.
Okay, I came from the perspective of an application developer and not so 
much as a contributor (which may, of yourse, change for bug reports and 
such)...




  * git only - no monticello meta info any more - possible?

Yes people use that everyday. But Pharo is not manage like that (even 
if we follow since years a git flow).
In Pharo 70 Pharo itself will be manage with iceberg with git as a 
back end (notice the difference)



So that will sure be a showcase for it being ready for prime time ;-)


  * tools like merge/diff, committing from within the image

You have all the diff merge tools within pharo

including local commits and oushes to the central repo?


  * dependencies within my own project as well as dependencies on
external code in - possibly multiple - external repositories

Metacello handles this since year.
There is a chapter on deep into pharo since ages


Okay, thanks! I'll definitely take a look at deep into Pharo.



  * what is the current "most official" source repository for open
source code?

SmalltalkHub and SS3,
I'm not surprised by these two, but I am surprised github is not in this 
list...



  * best practices for managing complex projects and keeping old
versions reproducible at any time

Use Metacello and use versions
or symbolic versions to your own projects if you want to minimize changes.

Okay, thanks.


  * tutorial for git newbies in a Pharo context? (Like, how do I start
with a new packege - create folder first and do git init, or start
in the image and push into repo later? as I said: beginners' stuff)

There is one on the the github of iceberg.
IIRC, iceberg will be in the Pharo 6 images by default..? So iceberg is 
what people are/will be using.



Again, thanks a lot for the pointers!


Joachim





Stef

On Wed, May 10, 2017 at 7:56 AM, Joachim Tuchel 
> wrote:


Hi guys,

please forgive me if this mail is a sign of ignorance. I am not a
regular Pharo user and one of the reasons for this is that I
didn't like most of the source management tools around Monticello.
Coming from an envy background, it feels like not being ready for
prime time. Of course you guys have been proving you can work with
these tools quite well, but still I'd be interested in using Pharo
in a pure git-based environment, as it most closely resembles some
of the most-beloved features of envy.

Over the years there was a lot of work and discussion on filetree,
gitfiletree, iceberg, cypress and maybe quite a few other projects
that sounded promising and interesting. But I must admit I lost
track of what was really done and how far things went in the last
years.

So are there any pointers to info material that I could look at to
see what the current status of source control in Pharo 5 and Pharo
6 is and/or will be soon?

I am mostly interested in these topics:

  * git only - no monticello meta info any more - possible?
  * tools like merge/diff, committing from within the image
  * dependencies within my own project as well as dependencies on
external code in - possibly multiple - external repositories
  * what is the current "most official" source repository for open
source code?
  * best practices for managing complex projects and keeping old
versions reproducible at any time
  * tutorial for git newbies in a Pharo context? (Like, how do I
start with a new packege - create folder first and do git
init, or start in the image and push into repo later? as I
said: beginners' stuff)

Thanks for pointers and help


Joachim






--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Re: [Pharo-users] Epicea vs RB refactorings

[Stephane Ducasse]

Nonsense
Epicea has nothing to do with RB goals.

Epicea is to replace the changes file because we want a better change file
and separate
the code management from the version recording (micro commits).

Source code could be managed in a separate database and microchanges
can be managed to recover changes but not actually showing the latest
version of a method.

Stef

Stef

On Wed, Apr 26, 2017 at 11:19 AM, Peter Uhnak  wrote:

> Hi,
>
> I'm under the impression that Epicea is supposed to replace RB
> refactorings at some point.
>
> If that is true, is it currently possible to build refactorings by hand?
>
> For example in RB I often do:
>
> ```
> model := RBNamespace new.
>
> model defineClass: ('<1s> subclass: #<2s>instanceVariableNames:
> <3p>classVariableNames: poolDictionaries:
> category: <4p>' expandMacrosWith: 'Object' with: 'MySomething'
> with: 'var1 var2' with: 'MyPackage').
> cls := model classNamed: #MySomething.
> cls compile: 'var1
> ^ var1' classified: 'accessing'.
>
> (ChangesBrowser changes: model changes changes) open
> ```
>
> or
>
> (removing a method from a class)
> ```
> model := RBNamespace new.
> model removeMethod: #testTrimRight from: StringTest.
> (ChangesBrowser changes: model changes changes) open
> ```
>
> Thanks,
> Peter
>
>

Re: [Pharo-users] Intro to git-only Pharo

[Stephane Ducasse]

Hi joachim

There is a distinction between managing projects and pharo. Pharo 60 is
managed with Monticello.
Pharo 70 will not.


   - git only - no monticello meta info any more - possible?

Yes people use that everyday. But Pharo is not manage like that (even if we
follow since years a git flow).
In Pharo 70 Pharo itself will be manage with iceberg with git as a back end
(notice the difference)


   - tools like merge/diff, committing from within the image

You have all the diff merge tools within pharo

   - dependencies within my own project as well as dependencies on external
   code in - possibly multiple - external repositories

Metacello handles this since year.
There is a chapter on deep into pharo since ages

   - what is the current "most official" source repository for open source
   code?

SmalltalkHub and SS3,

   - best practices for managing complex projects and keeping old versions
   reproducible at any time

Use Metacello and use versions
or symbolic versions to your own projects if you want to minimize changes.

   - tutorial for git newbies in a Pharo context? (Like, how do I start
   with a new packege - create folder first and do git init, or start in the
   image and push into repo later? as I said: beginners' stuff)

There is one on the the github of iceberg.

Stef

On Wed, May 10, 2017 at 7:56 AM, Joachim Tuchel 
wrote:

> Hi guys,
>
> please forgive me if this mail is a sign of ignorance. I am not a regular
> Pharo user and one of the reasons for this is that I didn't like most of
> the source management tools around Monticello. Coming from an envy
> background, it feels like not being ready for prime time. Of course you
> guys have been proving you can work with these tools quite well, but still
> I'd be interested in using Pharo in a pure git-based environment, as it
> most closely resembles some of the most-beloved features of envy.
>
> Over the years there was a lot of work and discussion on filetree,
> gitfiletree, iceberg, cypress and maybe quite a few other projects that
> sounded promising and interesting. But I must admit I lost track of what
> was really done and how far things went in the last years.
>
> So are there any pointers to info material that I could look at to see
> what the current status of source control in Pharo 5 and Pharo 6 is and/or
> will be soon?
>
> I am mostly interested in these topics:
>
>- git only - no monticello meta info any more - possible?
>- tools like merge/diff, committing from within the image
>- dependencies within my own project as well as dependencies on
>external code in - possibly multiple - external repositories
>- what is the current "most official" source repository for open
>source code?
>- best practices for managing complex projects and keeping old
>versions reproducible at any time
>- tutorial for git newbies in a Pharo context? (Like, how do I start
>with a new packege - create folder first and do git init, or start in the
>image and push into repo later? as I said: beginners' stuff)
>
> Thanks for pointers and help
>
>
> Joachim
>
>
>