Re: [Pharo-users] [Pharo-dev] [ANN] Pharo Consortium New Bronze Member: Palantir Solutions

[Tudor Girba]

Excellent news!

Doru


> On Jun 6, 2017, at 2:53 PM, Marcus Denker  wrote:
> 
> The Pharo Consortium is very happy to announce that Palantir Solutions
> has joined the Consortium as a Bronze Member.
> 
> About
> - Palantir Solutions: https://www.petrovr.com
> - Pharo Consortium: http://consortium.pharo.org
> 
> The goal of the Pharo Consortium is to allow companies and institutions to
> support the ongoing development and future of Pharo.
> 
> Individuals can support Pharo via the Pharo Association:
> 
> - http://association.pharo.org
> 

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

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

Re: [Pharo-users] [ARTICLE] Quick write me a Redis client

[Tudor Girba]

Nice job, Sven!

Doru


> On Jun 14, 2017, at 2:31 PM, Sven Van Caekenberghe  wrote:
> 
> Hi,
> 
> I wrote another article in the 'Concerning Pharo' publication:
> 
> [TITLE] Quick write me a Redis client
> [SUBTITLE] A beautiful protocol makes implementation easy
> [URL] 
> https://medium.com/concerning-pharo/quick-write-me-a-redis-client-5fbe4ddfb13d
> [SOURCECODE] https://github.com/svenvc/SimpleRedisClient
> 
> Sven
> 
> 
> --
> Sven Van Caekenberghe
> Proudly supporting Pharo
> http://pharo.org
> http://association.pharo.org
> http://consortium.pharo.org
> 
> 
> 
> 
> 

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

"Quality cannot be an afterthought."

Re: [Pharo-users] Metacello / Iceberg flags

[Tudor Girba]

Hi,

It is a setting.

You can search for it in the Settings browser (Enable Metacello integration), 
or execute the following:
Iceberg enableMetacelloIntegration: true.

Cheers,
Doru


> On Jun 15, 2017, at 3:22 PM, Alistair Grant  wrote:
> 
> Hi All,
> 
> I'm sure I saw a message on this list (maybe pharo-dev) that specified a
> flag that will cause github repositories loaded through Metacello to be
> automatically added to Iceberg.
> 
> My memory is that it was on prior to the Pharo 6 release, and turned off
> just before the release.
> 
> I've searched through the mailing list archives, but haven't been able
> to find it.
> 
> Can someone kindly help my failing memory?
> 
> Thanks,
> Alistair
> 
> 

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

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

Re: [Pharo-users] [ANN] success story: surgery appointments digitalised

[Tudor Girba]

Nice work!

Doru


> On Jun 22, 2017, at 2:40 PM, Norbert Hartl  wrote:
> 
> I'm sorry I forgot to post this much earlier. Anyway….
> 
> We are proud to add another success story to the pharo portfolio
> 
> http://zweidenker.de/en/project/operationstermine-digitalisiert
> 
> It is an operation planning tool for an eye surgery clinic. The core system 
> is pharo4 and voyage (using mongo). The user interface is done with seaside. 
> It interfaces with a legacy patient information system, microsoft exchange 
> and other stuff in order to orchestrate the arrangement of surgery dates. The 
> tool automates planning (which doctor works on which day and has still time 
> to do the operation,….). Finalized plans are produced in PDF an printed by 
> the staff.
> 
> This as a short info. If you have question don't hesitate to ask.
> 
> Implanting more pharo everywhere :)
> 
> Norbert
> 

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

"Be rather willing to give than demanding to get."

Re: [Pharo-users] [Glass] How do you develop for gemstone in open source tools (pharo)?

[Tudor Girba]

Hi,

gt4gemstone is indeed a new project. The initial target of gt4gemstone is 
actually to support scenario 3). In this situation, even if you develop in 
Pharo, once you deploy your application you still want to be able to 
inspect/debug GemStone. In this situation, you want to have the same experience 
as you do in Pharo, including the extensions to the tools.

Indeed, the project also contains an initial code browser (including 
senders/implementors) and its first target to support quick code modifications. 
Of course, that browser can evolve and this can lead to a full fledged 
experience of completely developing remotely from Pharo to GemStone.

Calypso is indeed a very interesting project, but at the moment it is Pharo 
specific. One thing Andrei did in gt4gemstone is serialize the Glamour 
presentations and browsers. This is quite powerful and fast and adds another 
argument to the idea that browsers should be built mostly declarative. One 
direction we brainstormed about with Denis is to learn from the experience of 
both gt4gemstone and Calypso and find a common ground. But, this is future work.

Cheers,
Doru


> On Jun 23, 2017, at 1:03 PM, Mariano Martinez Peck  
> wrote:
> 
> 
> 
> On Thu, Jun 22, 2017 at 6:16 PM, Petr Fischer via Glass 
>  wrote:
> Hello, I'm curious how _comfortably_ develop software for Gemstone, which is 
> the preferred/best way (and future)?
> 
> 1) tODE - OK, a decent amount of work was inserted to it to make it work 
> somehow. Decent tools with git support, a lot of windows (autolayouting 
> required), very basic inspector, based on obsolete Pharo3, no autocomplete, 
> weird auto code formating etc. :(
> Will the development continue (better inspectors, autocomplete, etc)?
> 
> 2) gt4gemstone - new project based on GT tools, great 
> playground/workspace/inspectors, running in latest Pharo, but again, just 
> basic browser, no autocompletion, no syntax coloring (so far), but modern way
> What is the plan? Write proper class browser and code editor again from 
> scratch?
> There is amazing new browser for Pharo, Calypso, which has remote browsing 
> capabilities (but probably different remoting/proxy layer than gt tools) - is 
> possible to utilize this project for remote Gemstone browsing in future?
> 
> 3) develop in Pharo, then deploy to Gemstone
> With some compatibility layers, there is possibility to develop 
> application/business logic in Pharo (with bare collections, dicts, containers 
> etc.) and then deploy code to Gemstone and test. Nice scenario, latest modern 
> dev tools (browsers, inspectors, versioning) from Pharo, but on the dev side 
> in Pharo, no transaction logic (test transaction logic with junit 
> impossible/not available etc.), also not compatible class library - so also 
> with drawbacks with different Smalltalk implementation chaos :( 
> I would very much like to get involved with Gemstone dev, but it scratches a 
> bit now.
> 
> 
> Hi Hi Petr,
> 
> I personally do 3). I like developing on Pharo and keep doing that on each 
> latest stable release. And yeah, you must have some compatibility layers, you 
> must keep a ConfigurationOf working on both platforms, different class 
> libraries (files, etc), etc. This takes time at the beginning, but then it 
> gets easier and easier. I still use tODE for evaluating code (workspace), 
> browsing GemStone specific code (browser), debug (stored continuations), and 
> for developing the GemStone specific code. 
> 
> 
> 4)
> 
> I think you made a good summary. In all those cases, you still consider 
> GemStone like both things, the language interpreter PLUS the persistency. 
> There is one last approach which uses GemStone mostly only for "persistence". 
> In this scenario you would use GemStone similarly to what you do with a 
> normal relational DB, that is, you open a connection, then do something.  
> Dale went a bit further and developed a simple Voyage kind of API with this 
> idea in mind. Anyway, below are some interesting links. 
> 
> 
> [0] 
> https://github.com/GsDevKit/gsDevKitHome/blob/dev/docs/articles/gsDevKitServerBlocks.md
> [1] https://github.com/dalehenrich/Tugrik
> 
> [2] https://github.com/dalehenrich/voyage
> 
> [3] http://www.slideshare.net/esug/tugrik-a-new-persistence-option-for-pharo
> 
> 
>  
> Thanks! pf
> ___
> Glass mailing list
> gl...@lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com

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

"There are no old things, there are only old ways of looking at them."

Re: [Pharo-users] Glamour: update presenter with new text

[Tudor Girba]

Hi Hilaire,

I think it does fit your problem.

However, I am not sure what the current problem is. Could you describe it again 
in more details?

Cheers,
Doru


> On Jul 5, 2017, at 5:10 PM, Hilaire  wrote:
> 
> May be my use case does not fit to Glamour, but I am tempted to think it 
> does. I really need help on that to make progress.
> 
> Thanks
> 
> Hilaire
> 
> Le 04/07/2017 à 23:08, Hilaire a écrit :
>> I added these lines of code, but it is not that yet:
>> 
>>  browser 
>>  updateOn: GLMItemAdded from: #yourself;
>>  updateOn: GLMItemRemoved from: #yourself.
>> 
>> 
> 
> -- 
> Dr. Geo
> 
> http://drgeo.eu

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

"It's not how it is, it is how we see it."

Re: [Pharo-users] Glamour: update presenter with new text

[Tudor Girba]

Hi,

I will try to follow up tomorrow.

Cheers,
Doru


> On Jul 12, 2017, at 6:01 PM, Hilaire  wrote:
> 
> Le 05/07/2017 à 19:43, Juraj Kubelka a écrit :
>> I have added the bold line from the previous
>> post: 
>> http://forum.world.st/Custom-Glamour-browser-for-Dr-Geo-scripting-tp4952920p4953209.html
>>  
>> 
>> But it is not perfect, because it does not keep the selection.
>> 
>> Hilaire, it looks like you are going to end up with a simplified
>> Nautilus/Calypso system editor. 
>> Maybe it is possible to take Calypso and find out how to simplify it
>> for your needs? 
>> Well, I am writing it without understanding your goal :-)
> 
> I read again carrefully your example and applied it to my case, and it
> does not work as I explained one week ago.
> And I am not sure I want to mess arround with Nautilus.
> I don't know what to do? Do you want a copy of my image to test it?
> 
> Hilaire
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

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

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

Re: [Pharo-users] Glamour: update presenter with new text

[Tudor Girba]

Hi,

I took a quick look. To get the methods properly update and selected when 
modifying code, you should use the reference to the method, and the not the 
compiled method.

Try this:

methodsIn: composite  
composite wrapper  title: 'Methods' translated;
show: [ :wrapper |
wrapper fastList 
display: [ :aClass | aClass methods collect: [ 
:m | m asRingDefinition ] ];
format: [ :aCompiledMethod | aCompiledMethod 
selector asString ] ].
composite wrapper title:  'Script data' translated;
show: [ :wrapper |
wrapper fastList 
display: [ :aClass | aClass class methods  
collect:  [ :m | m asRingDefinition ] ];
format: [ :aCompiledMethod | aCompiledMethod 
selector asString ] ].
composite updateOn: MethodModified from: [ SystemAnnouncer 
uniqueInstance ].

composite onChangeOfPort: #activePresentation act: [ :presentation | 
(presentation pane port: #activePresentation) value ifNotNil: [ 
:activePresentation | 
((browser paneNamed: #methods) port: #selection) value: 
(activePresentation defaultPane port: #selection) value ] ].


Cheers,
Doru


> On Jul 13, 2017, at 10:21 AM, Hilaire  wrote:
> 
> Le 13/07/2017 à 10:01, Denis Kudriashov a écrit :
>> What exactly you are implementing?
> Browsers to edit Dr. Geo user script. Explained in a previous mail of
> this thread.
> The idea is to show the user the strict minimum, to reduce confusion.
> 
> Hilaire
> 
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

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

"From an abstract enough point of view, any two things are similar."

Re: [Pharo-users] [FUN] Get ready to celebrate

[Tudor Girba]

Geeky :)

Doru


> On Jul 13, 2017, at 12:03 PM, Sven Van Caekenberghe  wrote:
> 
> https://en.wikipedia.org/wiki/Unix_time
> 
> "Right now"
> 
> DateAndTime now asUnixTime.
> 
> "Coming up"
> 
> DateAndTime fromUnixTime: 15.
> 
> "How long till then ?"
> 
> (DateAndTime fromUnixTime: 15) - DateAndTime now.
> 
> ;-)
> 
> Sven
> 

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

"We are all great at making mistakes."

Re: [Pharo-users] Glamour: update presenter with new text

[Tudor Girba]

Hi,

> On Jul 14, 2017, at 9:52 AM, Hilaire  wrote:
> 
> Thanks Doru, it works as a charm!

Great.

> I don't think I could find it by myself, or I will have to become a Glamour 
> expert.

Actually, this is not really related to Glamour, but to how CompiledMethods are 
dealt with by the system. A CompiledMethod is immutable, so every time you 
change a method, a new CompiledMethod object gets created. So, if the browser 
shows CompiledMethods, you will always see the old version. This would have 
been the same without Glamour as well. That is why you need to show a 
RingMethodDefinition which only holds a reference made by the name of the 
method that is resolved dynamically.


> To make it perfect, there is still a fix needed for the DrGeo script browser:
> 
> The class method 'scriptName' of each Dr. Geo script class returns a string, 
> it used in the browser (and other place) to list meaningfully the script (and 
> not use the generic class name).
> 
> Therefore, when the user edit this method, the script name listed in the left 
> panel should be updated accordingly. I edit the code as bellow:
> 
> scriptsIn: constructor
> constructor fastList
> title: 'Scripts' translated;
> display: [ :organiser |  organiser ];
> format: #scriptName.
> constructor  updateOn: MethodModified from: [ SystemAnnouncer 
> uniqueInstance ].
> 
> 
> It gives the expected behaviour. Is it the right way to do it?


constructor fastList creates a CompositePresentation that holds a 
ListPresentation. Think of a CompositePresentation as a morphic pane: it is a 
holder without much logic. The data you want to update is dealt with by 
ListPresentation. Thus, what you want to update is the list, not the whole 
composite.

scriptsIn: constructor
constructor fastList
title: 'Scripts' translated;
display: [ :organiser |  organiser ];
format: #scriptName;
updateOn: MethodModified from: [ SystemAnnouncer uniqueInstance 
].

Cheers,
Doru



> Thanks
> 
> Hilaire
> 
> 
> Le 13/07/2017 à 11:50, Tudor Girba a écrit :
>> 
>> I took a quick look. To get the methods properly update and selected when 
>> modifying code, you should use the reference to the method, and the not the 
>> compiled method.
>> 
> 
> -- 
> Dr. Geo
> 
> http://drgeo.eu

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

"Every successful trip needs a suitable vehicle."

Re: [Pharo-users] [ANN] PharoLambda a demo of Pharo running on AWS Lambda

[Tudor Girba]

Nice job!

Doru


> On Jul 15, 2017, at 1:43 AM, Tim Mackinnon  wrote:
> 
> Things move fast, I already got a shout out from an AWS advocate - 
> https://twitter.com/chrismunns/status/885959425860808704
> 
> Tim
> 
>> On 15 Jul 2017, at 00:39, Tim Mackinnon  wrote:
>> 
>> Hi - I’ve been playing around with getting Pharo to run well on AWS Lambda. 
>> It’s early days, but I though it might be interesting to share what I’ve 
>> learned so far.
>> 
>> Usage examples and code at https://gitlab.com/macta/PharoLambda
>> 
>> With help from many of the folks here, I’ve been able to get a simple 
>> example to run in 500ms-1200ms with a minimal Pharo 6 image. You can easily 
>> try it out yourself. This seems slightly better than what the GoLang folks 
>> have been able to do.
>> 
>> Tim
> 

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

"Every thing has its own flow."

Re: [Pharo-users] Critical issues for Dr. Geo on P6

[Tudor Girba]

Hi,

Can you detail your needs regarding the integration with Playground?

Cheers,
Doru


> On Jul 21, 2017, at 11:19 AM, Hilaire  wrote:
> 
> Hello people, 
> 
> Here are a few critical issues due to bugs or lack of information or feature 
> for porting Dr. Geo to P6. There were others critical issues from P6 but were 
> resolved and will be hopefully integrated, when ?
> 
>   • Minimal Dr. Geo image
>   • Integration with Playground
>   • Export bitmap to clipboard <-- it will be really cool to have.
>   • Universal package for 64 bits
> Other issues: https://launchpad.net/drgeo/+milestone/17.09
> 
> My  initial plane and need is to finish the porting and test by the end of 
> August. Not sure it sounds realistic.
> 
> Hilaire
> 
> -- 
> Dr. Geo
> 
> http://drgeo.eu

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

"It's not how it is, it is how we see it."

Re: [Pharo-users] Critical issues for Dr. Geo on P6

[Tudor Girba]

Aha. Thanks for the clarification.

Doru


> On Jul 21, 2017, at 8:59 PM, Hilaire  wrote:
> 
> The problem is explained in the ticket: there is a bug in the position where 
> the drgeo menu shows up when encapsulated in the Playground. It is not 
> related to Glamour however. I may just decide to remove the Dr. Geo menu to 
> avoid the bug.
> 
> 
> Le 21/07/2017 à 20:50, Tudor Girba a écrit :
>> Can you detail your needs regarding the integration with Playground?
> 
> -- 
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

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

“Live like you mean it."

Re: [Pharo-users] [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

[Tudor Girba]

Great job!

Doru


> On Jul 24, 2017, at 1:56 PM, Esteban Lorenzano  wrote:
> 
> Hi, 
> 
> We are releasing Pharo 6.1. 
> Usually, between each major version we just apply bugfixes changing the build 
> number and not announcing new versions but this time is different since the 
> fixes applied required a new VM. 
> The principal reason for the new version is to update Iceberg support, 
> bringing it to macOS 64bits version. 
> 
> So, now Pharo 6.1 comes with Iceberg 0.5.5, which includes: 
> 
> - running on macOS 64bits
> - adds cherry pick 
> - adds major improvements on performance for big repositories
> - adds pull request review plugin
> - repositories browser: group branches by remote
> - adds bitbucket and gitlab to recognised providers on metacello integration
> - uses libgit v0.25.1 as backend
> - several bugfixes
> 
> Other important change: 
> 
> - linux vm by default is now vm threaded heartbeat. 
> 
> We still miss 64bits Windows (sorry for that), but we are getting there. I 
> hope to have it running right after ESUG.
> 
> To download 6.1 version, you can go to http://pharo.org/download page, or 
> with zeroconf: 
> 
> wget -O- get.pharo.org | bash
> 
> Enjoy!
> Esteban

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

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

Re: [Pharo-users] GT Playground, pages dropdown menu - how does it work?

[Tudor Girba]

Hi,

The dropdown only shows the cached pages. It should be enhanced. Would you be 
interested in diving in to propose a change?

Doru



> On Aug 2, 2017, at 5:54 PM, Tim Mackinnon  wrote:
> 
> Hi - overtime I think I understand how the pages dropdown for the playground 
> works, it then doesn’t do what I expect?
> 
> I have learned that double clicking a page tab will put the page into the 
> stash directory with a name (which is cool), but then it doesn’t always seem 
> to appear in the dropdown list - however I have learned that Spotter will 
> find these pages if I use #playg…
> 
> So if spotter can find them, why does the playground dropdown seem to 
> temperamental, or am I missing some obvious trick for clearing a cache or 
> something like that? Or maybe its a bug? It would be nice if it would work, 
> as its very handy as quick way to swap to a script.
> 
> Tim

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

"Quality cannot be an afterthought."

Re: [Pharo-users] [ANN] PharoLambda 1.5 - Pharo running on AWS Lambda now with saved Debug sessions via S3

[Tudor Girba]

Very nice work, Tim!

It is quite impressive what you could do within a short amount of time 
(essentially since PharoDays). Please do keep this up.

Cheers,
Doru


> On Aug 10, 2017, at 3:47 PM, Tim Mackinnon  wrote:
> 
> I just wanted to thank everyone for their help in getting my pet project 
> further along, so that now I can announce that PharoLambda is now working 
> with the V7 minimal image and also supports post mortem debugging by saving a 
> zipped fuel context onto S3.
> 
> This latter item is particularly satisfying as at a recent serverless 
> conference (JeffConf) there was a panel where poor development tools on 
> serverless platforms was highlighted as a real problem.
> 
> In our community we’ve had these kinds of tools at our fingertips for ages - 
> but I don’t think the wider development community has really noticed. 
> Debugging something short lived like a Lambda execution is quite startling, 
> as the current answer is “add more logging”, and we all know that sucks. To 
> this end, I’ve created a little screencast showing this in action - and it 
> was pretty cool because it was a real example I encountered when I got 
> everything working and was trying my test application out.
> 
> I’ve also put a bit of work into tuning the excellent GitLab CI tools, so 
> that I can cache many of the artefacts used between different build runs 
> (this might also be of interest to others using CI systems).
> 
> The Gitlab project is on: https://gitlab.com/macta/PharoLambda
> And the screencast: https://www.youtube.com/watch?v=bNNCT1hLA3E
> 
> Tim
> 
> 
>> On 15 Jul 2017, at 00:39, Tim Mackinnon  wrote:
>> 
>> Hi - I’ve been playing around with getting Pharo to run well on AWS Lambda. 
>> It’s early days, but I though it might be interesting to share what I’ve 
>> learned so far.
>> 
>> Usage examples and code at https://gitlab.com/macta/PharoLambda
>> 
>> With help from many of the folks here, I’ve been able to get a simple 
>> example to run in 500ms-1200ms with a minimal Pharo 6 image. You can easily 
>> try it out yourself. This seems slightly better than what the GoLang folks 
>> have been able to do.
>> 
>> Tim
> 

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

"Quality cannot be an afterthought."

Re: [Pharo-users] [ANN] PharoLambda 1.5 - Pharo running on AWS Lambda now with saved Debug sessions via S3

[Tudor Girba]

+1

Doru


> On Aug 10, 2017, at 11:34 PM, Stephane Ducasse  
> wrote:
> 
> Tim
> 
> I definitively think that we could turn it into a Pharo success story
> or something that we can keep on the web site
> because it is really nice.
> 
> Stef
> 
> On Thu, Aug 10, 2017 at 3:47 PM, Tim Mackinnon  wrote:
>> I just wanted to thank everyone for their help in getting my pet project
>> further along, so that now I can announce that PharoLambda is now working
>> with the V7 minimal image and also supports post mortem debugging by saving
>> a zipped fuel context onto S3.
>> 
>> This latter item is particularly satisfying as at a recent serverless
>> conference (JeffConf) there was a panel where poor development tools on
>> serverless platforms was highlighted as a real problem.
>> 
>> In our community we’ve had these kinds of tools at our fingertips for ages -
>> but I don’t think the wider development community has really noticed.
>> Debugging something short lived like a Lambda execution is quite startling,
>> as the current answer is “add more logging”, and we all know that sucks. To
>> this end, I’ve created a little screencast showing this in action - and it
>> was pretty cool because it was a real example I encountered when I got
>> everything working and was trying my test application out.
>> 
>> I’ve also put a bit of work into tuning the excellent GitLab CI tools, so
>> that I can cache many of the artefacts used between different build runs
>> (this might also be of interest to others using CI systems).
>> 
>> The Gitlab project is on: https://gitlab.com/macta/PharoLambda
>> And the screencast: https://www.youtube.com/watch?v=bNNCT1hLA3E
>> 
>> Tim
>> 
>> 
>> On 15 Jul 2017, at 00:39, Tim Mackinnon  wrote:
>> 
>> Hi - I’ve been playing around with getting Pharo to run well on AWS Lambda.
>> It’s early days, but I though it might be interesting to share what I’ve
>> learned so far.
>> 
>> Usage examples and code at https://gitlab.com/macta/PharoLambda
>> 
>> With help from many of the folks here, I’ve been able to get a simple
>> example to run in 500ms-1200ms with a minimal Pharo 6 image. You can easily
>> try it out yourself. This seems slightly better than what the GoLang folks
>> have been able to do.
>> 
>> Tim
>> 
>> 
> 

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

"Reasonable is what we are accustomed with."

Re: [Pharo-users] [ann] moldable brick editor - alpha

[Tudor Girba]

Is this still an issue?

Could you also try on another OS (just to make sure)?

Cheers,
Doru


> On Aug 10, 2017, at 2:12 PM, stephan  wrote:
> 
> On 10-08-17 13:09, stephan wrote:
>> On 05-08-17 00:19, Tudor Girba wrote:
>> >Iceberg enableMetacelloIntegration: true.
>> That doesn't work. It hangs the image, keeping one CPU
>> busy.
> 
> With 60510 that is non-interruptable, b.t.w.
> 
> Stephan
> 
> 
> 
> 

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

"Problem solving efficiency grows with the abstractness level of problem 
understanding."

Re: [Pharo-users] including Pillar in Pharo image by default

[Tudor Girba]

Hi,

I would very much like this path. What would constitute tiny?

Cheers,
Doru


> On Aug 11, 2017, at 9:10 PM, Esteban Lorenzano  wrote:
> 
> hi, 
> 
>> On 11 Aug 2017, at 18:57, Cyril Ferlicot D.  wrote:
>> 
>> Another step would be to get a minimal parser not relying on
>> PetitParser. 
> 
> Let’s think differently: why not to include a tiny PetitParser? 
> Then we can think on:
> 
> - pillar sintax (better than just a restricted version)
> - simplify other “small parsers” that are already on the image.
> - we provide a tool to o cool stuff (instead relying as always in regexp, 
> etc.) 
> 
> cheers, 
> Esteban

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

"Beauty is where we see it."

Re: [Pharo-users] PetitParser: Parse X as long as it's not Y

[Tudor Girba]

Hi,

As Jan pointed out, you should use “not” instead of “negate and”.

Cheers,
Doru


> On Aug 10, 2017, at 5:22 AM, Sean P. DeNigris  wrote:
> 
> Peter Kenny wrote
>> You may need to post-process the parse to get what you
>> want.
> 
> Good point. I omitted several ` ==> #second` in several places for
> readability on the list, but we should mention that for posterity. Also, duh
> `gen negate and` should be `gen not`!
> 
> 
> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/PetitParser-Parse-X-as-long-as-it-s-not-Y-tp4958895p4959533.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> 

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

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

Re: [Pharo-users] including Pillar in Pharo image by default

[Tudor Girba]

Hi Tim,

The main benefit of relying on Pillar is that we control its syntax and can 
easily extend it for our purposes. Also, there was quite a bit of engineering 
invested in it, and even though we still need to improve it, there exists a 
pipeline that allows people to quickly publish books.

The figure embedding problem is one example of the need to customize the syntax 
and behavior, but this extensibility will become even more important for 
supporting the idea of moving the documentation inside the image. For example, 
the ability to refer to a class, method or other artifacts will be quite 
relevant soon especially that the editor will be able to embed advanced 
elements inside the text.

Cheers,
Doru


> On Aug 14, 2017, at 10:46 AM, Tim Mackinnon  wrote:
> 
> Hi Stef - I think your’s is a fair requirement (in fact I hit something 
> similar when doing a static website using a JS markdown framework - and this 
> is why I mentioned Kramdown which adds a few extras to regular markdown - but 
> it feels like it goes a bit too far).
> 
> My next item on my learning todo list was to try and replace that JS 
> generator with something from Smalltalk - so I think we can possibly come up 
> with something that ticks all the right boxes (I’d like to try anyway).
> 
> I’ll keep working away on it and compare notes with you. I think with Pillar, 
> it was more that things like headers, bold and italics are similar concepts 
> but just use different characters - so I keep typing the wrong thing and 
> getting frustrated particularly when we embrace Git and readme.md is in 
> markdown.
> 
> 
> Tim
> 
>> On 13 Aug 2017, at 20:08, Stephane Ducasse  wrote:
>> 
>> Hi tim
>> 
>> I personally do not care much about the syntax but I care about what I
>> can do with it
>> (ref, cite, ... )
>> I cannot write books in markdown because reference to figures!!
>> were missing.
>> 
>> And of course a parser because markdown is not really nice to parse
>> and I will not write a parser because I have something else to do. I
>> want to make pillar smaller, simpler, nicer.
>> 
>> Now if someone come up with a parser that parse for REAL a markdown
>> that can be extended with decent behavior (figure reference, section
>> reference, cite) and can be extended because there are many things
>> that can be nice to have (for example I want to be able to write the
>> example below) and emit a PillarModel (AST) we can talk to have
>> another syntax for Pillar but not before.
>> 
>> [[[test
>> 2+3
> 5
>> ]]]
>> 
>> and being able to verify that the doc is in sync.
>> 
>> 
>> Stef
>> 
>> 
>> 
>> On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon  wrote:
>>> Of course, I/we recognise and appreciate all the work that's gone into docs 
>>> in pillar - but I think it should be reasonably straightforward to write a 
>>> converter as it is pretty closely related from what I have seen.
>>> 
>>> So I don't make the suggestion flippantly, and would want to help write a 
>>> converter and get us to a common ground where we can differentiate on the 
>>> aspects where we can excel.
>>> 
>>> Tim
>>> 
>>> Sent from my iPhone
>>> 
 On 11 Aug 2017, at 23:21, Peter Uhnak  wrote:
 
 A long time issue with Markdown was that there was no standardization (and 
 when I used Pillar's MD export ~2 years ago it didn't work well).
 
 However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the 
 de-facto standard, so it would make sense to support it bidirectionally 
 with Pillar.
 
> The readme.md that Peter is talking about is gfm markdown
 
 Well, technically it is just a CommonMark, as I am not using any github 
 extensions.
 (Github uses CommonMarks and adds just couple small extensions.)
 
 Peter
 
>>> 
>>> 
>> 
> 
> 

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

“Live like you mean it."

Re: [Pharo-users] [Pharo-dev] including Pillar in Pharo image by default

[Tudor Girba]

Hi,


> On Aug 14, 2017, at 3:51 PM, Esteban Lorenzano  wrote:
> 
> again, I think this is a discussion for pharo-dev. 
> Please keep it there (is good discussion, btw ;) ).
> 
> What about my proposal of including a tiny PetitParser? (it would be 
> “InfimeParser” :P)

I am for it, but there will be some work to repackage PetitParser2.

Also, I notice that the French lessons start to pay off :)

Cheers,
Doru


> Esteban
> 
> 
>> On 14 Aug 2017, at 11:10, Tudor Girba  wrote:
>> 
>> Hi Tim,
>> 
>> The main benefit of relying on Pillar is that we control its syntax and can 
>> easily extend it for our purposes. Also, there was quite a bit of 
>> engineering invested in it, and even though we still need to improve it, 
>> there exists a pipeline that allows people to quickly publish books.
>> 
>> The figure embedding problem is one example of the need to customize the 
>> syntax and behavior, but this extensibility will become even more important 
>> for supporting the idea of moving the documentation inside the image. For 
>> example, the ability to refer to a class, method or other artifacts will be 
>> quite relevant soon especially that the editor will be able to embed 
>> advanced elements inside the text.
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Aug 14, 2017, at 10:46 AM, Tim Mackinnon  wrote:
>>> 
>>> Hi Stef - I think your’s is a fair requirement (in fact I hit something 
>>> similar when doing a static website using a JS markdown framework - and 
>>> this is why I mentioned Kramdown which adds a few extras to regular 
>>> markdown - but it feels like it goes a bit too far).
>>> 
>>> My next item on my learning todo list was to try and replace that JS 
>>> generator with something from Smalltalk - so I think we can possibly come 
>>> up with something that ticks all the right boxes (I’d like to try anyway).
>>> 
>>> I’ll keep working away on it and compare notes with you. I think with 
>>> Pillar, it was more that things like headers, bold and italics are similar 
>>> concepts but just use different characters - so I keep typing the wrong 
>>> thing and getting frustrated particularly when we embrace Git and readme.md 
>>> is in markdown.
>>> 
>>> 
>>> Tim
>>> 
>>>> On 13 Aug 2017, at 20:08, Stephane Ducasse  wrote:
>>>> 
>>>> Hi tim
>>>> 
>>>> I personally do not care much about the syntax but I care about what I
>>>> can do with it
>>>> (ref, cite, ... )
>>>> I cannot write books in markdown because reference to figures!!
>>>> were missing.
>>>> 
>>>> And of course a parser because markdown is not really nice to parse
>>>> and I will not write a parser because I have something else to do. I
>>>> want to make pillar smaller, simpler, nicer.
>>>> 
>>>> Now if someone come up with a parser that parse for REAL a markdown
>>>> that can be extended with decent behavior (figure reference, section
>>>> reference, cite) and can be extended because there are many things
>>>> that can be nice to have (for example I want to be able to write the
>>>> example below) and emit a PillarModel (AST) we can talk to have
>>>> another syntax for Pillar but not before.
>>>> 
>>>> [[[test
>>>> 2+3
>>>>>>> 5
>>>> ]]]
>>>> 
>>>> and being able to verify that the doc is in sync.
>>>> 
>>>> 
>>>> Stef
>>>> 
>>>> 
>>>> 
>>>> On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon  wrote:
>>>>> Of course, I/we recognise and appreciate all the work that's gone into 
>>>>> docs in pillar - but I think it should be reasonably straightforward to 
>>>>> write a converter as it is pretty closely related from what I have seen.
>>>>> 
>>>>> So I don't make the suggestion flippantly, and would want to help write a 
>>>>> converter and get us to a common ground where we can differentiate on the 
>>>>> aspects where we can excel.
>>>>> 
>>>>> Tim
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On 11 Aug 2017, at 23:21, Peter Uhnak  wrote:
>>>>>> 
>>>>>> A long time issue with Markdown was that there was no standardization 
>>>>>> (and when I used Pillar's MD export ~2 years ago it didn't work well).
>>>>>> 
>>>>>> However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the 
>>>>>> de-facto standard, so it would make sense to support it bidirectionally 
>>>>>> with Pillar.
>>>>>> 
>>>>>>> The readme.md that Peter is talking about is gfm markdown
>>>>>> 
>>>>>> Well, technically it is just a CommonMark, as I am not using any github 
>>>>>> extensions.
>>>>>> (Github uses CommonMarks and adds just couple small extensions.)
>>>>>> 
>>>>>> Peter
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com 
>> 
>> “Live like you mean it."
>> 
>> 
> 
> 

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

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

Re: [Pharo-users] Glamour: update presenter with new text

[Tudor Girba]

Hi Hilaire,

Sorry for the late reply.

Indeed, it should be possible to do this, but we have to look closer at your 
concrete code.

Here is an example:
browser := GLMTabulator new.
browser column: #one; column: #two.
browser transmit to: #one; andShow: [ :a |
a list display: [ :x | 1 to: x ] ].
browser transmit from: #one; to: #two; andShow: [ :a | a text ].
browser transmit 
fromOutsidePort: #explicitSelection;
to: #one port: #selection.
browser openOn: 42.
(browser pane port: #explicitSelection) value: 41

Essentially, you need to transmit the selection from the outside to the inside 
pane. Please note that once you pass the #explicitSelection to the #selection 
of pane #one, you also trigger the transmission from #one to #two, and this is 
why the 41 also appears in the text on the right hand side.

Does this help?

In the meantime, have you read this chapter:
http://www.themoosebook.org/book/index.html#h1buildingbrowserswithglamour
?



Cheers,
Doru


> On Jul 15, 2017, at 10:38 AM, Hilaire  wrote:
> 
> Thanks for the updates on both the internal dependencies and the 
> ListPresentation.
> 
> From this browser, I deduced a second simpler browser for only one script. It 
> was easy to do so thanks to your tips (attached pic).
> 
> With this simpler script editor, when I open a script, I like it opens on the 
> compute method, because it is a mandatory method in a script.
> 
> I was doing it like 
> 
> browser := Nautilus openOnClass: scriptClass selector: #compute.
> 
> I guess, there is a way to do so with the Glamour browser ?
> 
> Thanks
> 
> Hilaire
> 
> -- 
> Dr. Geo
> 
> http://drgeo.eu
> 

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

"Every now and then stop and ask yourself if the war you're fighting is the 
right one."

Re: [Pharo-users] PetitParser catalog entry for Pharo 6.0/6.1? (Re: YAML parser (2017))

[Tudor Girba]

Hi Hannes,

Indeed, we did not yet release PetitParser for Pharo 6.0. We delayed a bit too 
long this release.

In the meantime, here is a script that automates what you are loading manually:

Metacello new
smalltalkhubUser: 'Moose' project: 'PetitParser';
configuration: 'PetitParser';
version: #development;
load.
Gofer new
smalltalkhubUser: 'Moose' project: 'PetitParser';
package: 'PetitYAML';
load.


Cheers,
Doru


> On Aug 24, 2017, at 11:49 AM, H. Hirzel  wrote:
> 
> Hello Doru
> 
> Stephane Ducasse pointed out that you maintain PetitParser [1]
> 
> The Pharo 6 catalog does not contain an entry for the PetitParser package.
> 
> I installed in manually in order to have a good version of a YAML
> parser (all tests green).
> 
> This is what I did:
> 
> a)
> I loaded ConfigurationOfPetitParser-TudorGirba.80 through the
> Monticello Browser (not the catalog) into Pharo 6
> 
> b) Then I executed
> 
>   ConfigurationOfPetitParser load
> 
> c) I manually loaded
>Name: PetitYAML-PhilippeBack.11
>Author: PhilippeBack
>Time: 29 May 2017, 12:53:55.994195 pm
>UUID: d7658233-112c-754c-81a7-d60139bb9549
> 
> 
> My need:
> 
> I'd like to have a Pillar installation in 6.0 together with a
> PetitParser version which supports the YAML parser version with the
> latest fixes by Philippe Back. At the moment I  have Pillar and the
> manually loaded PetitParser in two different Pharo 6.1 images.
> 
> 
> Thank you in advance
> Regards
> Hannes
> 
> 
> 
> On 8/22/17, Stephane Ducasse  wrote:
>> Hi Hannes
>> 
>> you should report this to doru.
>> 
>> Stef
>> 
>> On Sat, Aug 19, 2017 at 8:36 PM, H. Hirzel  wrote:
>>> On 8/19/17, Peter Uhnak  wrote:
 On Sat, Aug 19, 2017 at 02:45:28PM +0200, H. Hirzel wrote:
> Peter, thanks for the confirmation that in your installation of the
> PetitYAML grammar all tests are green.
> 
> I wonder how you did it.
 

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

"If you can't say why something is relevant, 
it probably isn't."

Re: [Pharo-users] SmartTest - ESUG 2017 - Trailer

[Tudor Girba]

The bar is getting higher :)

Doru


> On Aug 24, 2017, at 10:18 PM, Stephane Ducasse  
> wrote:
> 
> :)
> Ready for the ESUG innovation award competition.
> 
> 
> On Thu, Aug 24, 2017 at 6:49 PM, Dimitris Chloupis
>  wrote:
>> lol by far the most funny pharo teaser I have watched and the tool looks
>> extra useful , well done :)
>> 
>> On Thu, Aug 24, 2017 at 6:33 PM Benoit Verhaeghe 
>> wrote:
>>> 
>>> Hi everyone,
>>> 
>>> I'm glad to present you the trailer of SmartTest for ESUG
>>> https://www.youtube.com/watch?v=jAvfdN2z5-s
>>> 
>>> Benoît Verhaeghe
> 

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

"No matter how many recipes we know, we still value a chef."

Re: [Pharo-users] [Pillar] Installed the Pillar document preparation system into 6.1, how do I start using it?

[Tudor Girba]

On Aug 25, 2017, at 8:53 AM, Norbert Hartl  wrote:
> 
> 
>> Am 24.08.2017 um 22:34 schrieb Stephane Ducasse :
>> 
>> In Pharo 60 (and not in Pharo 50) I extracted the command line logic
>> into a specific object so that we do not have to be bound to use the
>> command line. You can have a look in the CLI package.
>> 
>> This is good that there is Section 7 this in the doc. We started to
>> build a simple Morphic renderer for Pillar.
>> We should continue. If someone wants to have fun. This would be nice
>> to have see it coming to live.
>> 
> A morphic renderer? Wouldn't it be fun to do one for bloc? I think we should 
> slowly collect some tools that use bloc in order to get the tension making it 
> the "default" thingie.

On its way :)

Doru


>> On my todo: I also want to use mustache inside Pharo and not
>> generating files on the disk.
>> 
> That should be doable by deleting some code.
> 
> Norbert
> 
>> Stef
>> 
>> On Fri, Aug 18, 2017 at 10:08 PM, H. Hirzel  wrote:
>>> Exactly.
>>> 
>>> Section 7 of
>>> https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/PillarChap/Pillar.html
>>> 
>>> has an example
>>> 
>>> 
>>>   | wiki |
>>>   wiki := '!My Document'.
>>>   PRPillarParser parse: wiki
>>> 
>>> 
>>> Or
>>> 
>>>   PRPillarParser parse: (FileSystem workingDirectory / 'foo.pillar')
>>> readStream
>>> 
>>> 
>>> and then
>>> 
>>> 
>>>   PRHTMLWriter write: document
>>> 
>>> 
>>> This put together gives
>>> 
>>>   PRHTMLWriter write: (
>>>   PRPillarParser parse: (FileSystem workingDirectory / 'welcome.pillar')
>>>   )
>>> 
>>> 
>>> If I inspect the result of this expression I get the HTML string.
>>> 
>>> Thank you Cyril. This is what I was looking for.
>>> 
>>> --Hannes
>>> 
>>> 
>>> 
>>> 
>>> On 8/18/17, Cyril Ferlicot  wrote:
 On ven. 18 août 2017 at 21:43, H. Hirzel  wrote:
 
> Thank you Cyril for the link to the tutorial.
> 
> 
> https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/PillarChap/Pillar.html
> 
> I see that Pillar is a command line tool. The welcome example taken
> from this tutorial is:
> 
>   Pharo.exe Pillar.image pillar export --to=html
> --outputFile=welcome welcome.pillar
> 
> How can I run a command like this from within Pharo in a "playground"
> (former workspace)?
> 
> Later on I plan to construct a simple GUI with text boxes for Pillar
> sources and have some buttons executing these commands.
> 
> --Hannes
> 
> 
 
 I remember writing a part "Pillar from Pharo" in this doc. I'm not sure it
 is still up to date but you can try to check part 7 of the doc I sent.
 --
 Cyril Ferlicot
 https://ferlicot.fr
 
 http://www.synectique.eu
 2 rue Jacques Prévert 01,
 59650 Villeneuve d'ascq France
 
>>> 
> 

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

"Problem solving efficiency grows with the abstractness level of problem 
understanding."

Re: [Pharo-users] Morphic renderer for Pillar?

[Tudor Girba]

Hi,

Just for information: Pillar already ships with a live editor with syntax 
highlighting that I built a couple of years ago.

And there are two inspector presentations available:
- If you inspect a class, you will get a Pillar comment presentation with 
syntax highlighting
- If you inspect a .pillar file, you will get a Pillar editor with syntax 
highlighting

Cheers,
Doru


> On Aug 26, 2017, at 12:15 AM, Cyril Ferlicot D.  
> wrote:
> 
> Le 25/08/2017 à 11:04, H. Hirzel a écrit :
>> Hello Stephane
>> 
>> On 8/24/17, Stephane Ducasse  wrote:
>> [...]
>>> 
>>> This is good that there is Section 7 this in the doc. [1] We started to
>>> build a simple Morphic renderer for Pillar.
>>> We should continue. If someone wants to have fun. This would be nice
>>> to have see it coming to live.
>> 
>> I am interested in this. Where is the code?
>> 
>> BTW if other people want to do a Pillar renderer for Bloc I have no
>> problem with that.
>> :-;
>> [...]
>> 
>> Regards
>> --Hannes
>> 
>> 
>> [1] 
>> https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/PillarChap/Pillar.html
>> 
> 
> Hi,
> 
> Back in 2015 there was Kasper Østerbye who did a Pillar-TextRenderer
> 
> There is a screen slide 21:
> http://esug.org/data/ESUG2015/4%20thursday/1600-1630%20Pilar/Pillar.pdf
> 
> Here is the thread:
> http://forum.world.st/Class-comments-rendered-in-Nautilus-through-Pillar-td4819726.html
> 
> -- 
> Cyril Ferlicot
> https://ferlicot.fr
> 
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France
> 

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

"Not knowing how to do something is not an argument for how it cannot be done."

Re: [Pharo-users] [ann] moldable editor - with expandable elements

[Tudor Girba]

Hi,

This is achieved through the integration in Morphic we announced a couple of 
months ago. Now, Sparta offers:
- two backends: Moz2D and Cairo
- two host systems: SDL2 and Morphic

By default, Bloc ships with Sparta working on Cairo and Morphic, and with this 
you can use any Bloc element inside a morph. Glamour also comes with a 
BlocPresentation that makes use of this ability, and this is what you see in 
the picture.

So, it is possible to use this inside Morphic, and our effort will be focused 
exclusively around this editor.

Cheers,
Doru



> On Aug 26, 2017, at 11:44 AM, Denis Kudriashov  wrote:
> 
> I wondering how you compose bloc component inside morphic inspector? (which 
> is shown in your pictures)
> Did you already have GT inspector in Bloc?
> Is it posible to use this editor in morphic? Can we replace rubric?
> 
> 2017-08-26 1:03 GMT+02:00 Tudor Girba :
> Hi,
> 
> We are really pleased to announce another major advancement in the 
> development of the moldable editor, and most of it was enabled because of one 
> new feature: expandable elements. We think this will impact significantly our 
> day to day interactions.
> 
> To exemplify what we mean, we will make use of two more alpha projects that 
> we did not announce yet: GT Documenter (a set of documentation tools based on 
> Pillar and GT Examples) and GT Mondrian (the graph visualization engine), 
> both of which are being implemented in Bloc.
> 
> Please take a look at the following pictures showing the documentation Pillar 
> file that ships together with GT Mondrian. What stands out are the two 
> embedded pictures. These are actually not pictures, but visualizations 
> rendered live during the viewing of the document out of a referenced GT 
> Example.
> 
> 
> 
> Now, GT Examples are likely also new for most people. We introduced them a 
> couple of years ago based on the original idea of Markus Gaelli. These are a 
> kind of tests that return an object and that can be built out of other 
> examples. The nice thing is that they are always executable and testable. So, 
> of course, if you see the resulting object,  you can also see the code that 
> created it, and if you see the code, you can even execute it live, right in 
> place (notice the preview of the second snippet).
> 
> 
> 
> Perhaps the most controversial part of GT Examples is that they offer a 
> mechanism to define static dependencies via pragmas. Please, let’s leave this 
> debate to another occasion, but please also notice that tools can use that 
> static information to unfold the code of the referenced method (notice the 
> nested code editors).
> 
> A side note: if you look closer at the list with three items at the top of 
> the Tutorial section, you will notice numbering next to #. That is actually 
> syntax highlighting and so is the mechanism that embeds the expandable 
> elements. It’s really cool.
> 
> Taking step back, when we introduced the editor a few weeks ago, we called it 
> moldable because we said we can make it take different shapes easily. GT 
> Documenter with everything you see in the above screenshots has currently 
> ~500 lines of code, and all this while still having an editor that is highly 
> scalable.
> 
> We think that Bloc and Brick will change dramatically face of Pharo and now 
> we can start to get a glimpse of what is possible. For example, the use case 
> presented above is more than a technical tool, and we think this will change 
> both the way we write documentation and the way we consume it.
> 
> All these will be presented at ESUG both during presentations and at the 
> Innovation Awards competition. In the meantime, those that want to play with 
> it can execute the following in both Pharo 6.1 and Pharo 7.0:
> 
> Iceberg enableMetacelloIntegration: true.
> Metacello new
>baseline: 'GToolkit';
>repository: 'github://feenkcom/gtoolkit/src';
>load.
> 
> And then inspect:
> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' 
> asFileReference
> 
> Cheers,
> The feenk team
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Innovation comes in the least expected form. 
> That is, if it is expected, it already happened."
> 
> 

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

"Every successful trip needs a suitable vehicle."

Re: [Pharo-users] [Pillar] How do I open the Pillar editor in Pharo 6?

[Tudor Girba]

In an image having Pillar, inspect a Pillar file. Something like this:

‘path/to/file.pillar' asFileReference

Cheers,
Doru


> On Aug 26, 2017, at 9:56 AM, H. Hirzel  wrote:
> 
> Hello Doru
> 
> On 8/26/17, Tudor Girba  wrote:
>> Hi,
>> 
>> Just for information: Pillar already ships with a live editor with syntax
>> highlighting that I built a couple of years ago.
> 
> Thank you for this information, Doru.
> 
> Earlier this week I was looking for a "Pillar tool" in Pharo 6 and was
> told, that there is none.
> I did not find a link in the help system nor a menu entry in the world menu.
> 
> How do I get at this live editor?
> 
>> And there are two inspector presentations available:
>> - If you inspect a class, you will get a Pillar comment presentation with
>> syntax highlighting
>> - If you inspect a .pillar file, you will get a Pillar editor with syntax
>> highlighting
>> 
>> Cheers,
>> Doru
>> 
> 
> 
> Regards
> Hannes

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

"Quality cannot be an afterthought."

Re: [Pharo-users] [Moose-dev] [ann] moldable editor - with expandable elements

[Tudor Girba]

Hi Tim,

Thanks for the kind words. What you see now is only the first more tangible 
effect of what Bloc represents. Expect significantly more :).

Cheers,
Doru


> On Aug 26, 2017, at 9:56 AM, Tim Mackinnon  wrote:
> 
> Guys - this is absolutely astounding. 6 months ago I tagged a tweet with 
> #pharoproject about why we put up with static source code when we can do so 
> much more, and I'm stunned that in literally months this is a evolving around 
> us.
> 
> This community is awesome! 
> 
> Tim
> 
> Sent from my iPhone
> 
> On 26 Aug 2017, at 01:03, Tudor Girba  wrote:
> 
>> Hi,
>> 
>> We are really pleased to announce another major advancement in the 
>> development of the moldable editor, and most of it was enabled because of 
>> one new feature: expandable elements. We think this will impact 
>> significantly our day to day interactions.
>> 
>> To exemplify what we mean, we will make use of two more alpha projects that 
>> we did not announce yet: GT Documenter (a set of documentation tools based 
>> on Pillar and GT Examples) and GT Mondrian (the graph visualization engine), 
>> both of which are being implemented in Bloc.
>> 
>> Please take a look at the following pictures showing the documentation 
>> Pillar file that ships together with GT Mondrian. What stands out are the 
>> two embedded pictures. These are actually not pictures, but visualizations 
>> rendered live during the viewing of the document out of a referenced GT 
>> Example.
>> 
>> 
>> 
>> Now, GT Examples are likely also new for most people. We introduced them a 
>> couple of years ago based on the original idea of Markus Gaelli. These are a 
>> kind of tests that return an object and that can be built out of other 
>> examples. The nice thing is that they are always executable and testable. 
>> So, of course, if you see the resulting object,  you can also see the code 
>> that created it, and if you see the code, you can even execute it live, 
>> right in place (notice the preview of the second snippet).
>> 
>> 
>> 
>> Perhaps the most controversial part of GT Examples is that they offer a 
>> mechanism to define static dependencies via pragmas. Please, let’s leave 
>> this debate to another occasion, but please also notice that tools can use 
>> that static information to unfold the code of the referenced method (notice 
>> the nested code editors).
>> 
>> A side note: if you look closer at the list with three items at the top of 
>> the Tutorial section, you will notice numbering next to #. That is actually 
>> syntax highlighting and so is the mechanism that embeds the expandable 
>> elements. It’s really cool.
>> 
>> Taking step back, when we introduced the editor a few weeks ago, we called 
>> it moldable because we said we can make it take different shapes easily. GT 
>> Documenter with everything you see in the above screenshots has currently 
>> ~500 lines of code, and all this while still having an editor that is highly 
>> scalable.
>> 
>> We think that Bloc and Brick will change dramatically face of Pharo and now 
>> we can start to get a glimpse of what is possible. For example, the use case 
>> presented above is more than a technical tool, and we think this will change 
>> both the way we write documentation and the way we consume it.
>> 
>> All these will be presented at ESUG both during presentations and at the 
>> Innovation Awards competition. In the meantime, those that want to play with 
>> it can execute the following in both Pharo 6.1 and Pharo 7.0:
>> 
>> Iceberg enableMetacelloIntegration: true.
>> Metacello new
>>baseline: 'GToolkit';
>>repository: 'github://feenkcom/gtoolkit/src';
>>load.
>> 
>> And then inspect:
>> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' 
>> asFileReference
>> 
>> Cheers,
>> The feenk team
>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "Innovation comes in the least expected form. 
>> That is, if it is expected, it already happened."
>> 
>> ___
>> Moose-dev mailing list
>> moose-...@list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev

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

"There are no old things, there are only old ways of looking at them."

Re: [Pharo-users] [ann] moldable editor - with expandable elements

[Tudor Girba]

ain?
>>  
>> But as Tim notice it always loses context. And it is quite difficult to 
>> browse long call chain which include many small methods.
>> 
>> I'm not sure it would solve that one.
>> 
>> Either it is a long call chain with a fan-out of one, in which case the 
>> developper is creating many useless single line methods because it is "the 
>> right way"(tm), or it has a fan-out greater than one (your typical 
>> polymorphic code) and then each time you open, you have half a dozen 
>> implementors.
>> 
>> For that, you already have the flow browser.
>>  
>> So with new editor command+click will be able expand implementor just in 
>> place. I think it will be big improvement for IDE. 
>> 
>> As I said, with Calypso and Nautilus handling badly long methods, then a 
>> method inside a method just makes the top level method longer... I'd like to 
>> see you do that on Metacello or SmaCC code, where important methods easily 
>> go over 50 lines before you expand anything.
>> 
>> I'd say there that the GTInspector approach would work better -> expand on 
>> the right, with the ability to keep two side by side, and overlaid with 
>> lines clearly showing what has been expanded (for that "context" thing).
>> 
>> Regards,
>> 
>> Thierry
>>  
>> 
>> 2017-08-26 14:59 GMT+02:00 Thierry Goubier :
>> 
>> 
>> 2017-08-26 14:46 GMT+02:00 Denis Kudriashov :
>> 
>> 2017-08-26 14:31 GMT+02:00 Tim Mackinnon :
>> Denis - that's a very cool idea if I've understood you - expand in the 
>> source code of the current method, literally inline? So you could scroll up 
>> and down to view the context as you expand it out?
>> 
>> Yes, exactly.
>> 
>> Then that would look a bit like the NewSpeak code browser, if you would like 
>> to try the concept.
>> 
>> There are disadvantages to that paradigm. One of those is that the system 
>> browser in Pharo is ill-suited to long methods.
>> 
>> Thierry
>>  
>>  
>> One of the complaints around refactoring is that you lose context of 
>> surrounding code - intelligent in place expansion would be the best of both 
>> worlds...
>> 
>> Tim
>> 
>> Sent from my iPhone
>> 
>> On 26 Aug 2017, at 11:40, Denis Kudriashov  wrote:
>> 
>>> This is really cool. It opens so many possibilities.
>>> 
>>> I imaging method editor where message sends can be expanded to implementors 
>>> just in place.
>>> 
>>> 2017-08-26 1:03 GMT+02:00 Tudor Girba :
>>> Hi,
>>> 
>>> We are really pleased to announce another major advancement in the 
>>> development of the moldable editor, and most of it was enabled because of 
>>> one new feature: expandable elements. We think this will impact 
>>> significantly our day to day interactions.
>>> 
>>> To exemplify what we mean, we will make use of two more alpha projects that 
>>> we did not announce yet: GT Documenter (a set of documentation tools based 
>>> on Pillar and GT Examples) and GT Mondrian (the graph visualization 
>>> engine), both of which are being implemented in Bloc.
>>> 
>>> Please take a look at the following pictures showing the documentation 
>>> Pillar file that ships together with GT Mondrian. What stands out are the 
>>> two embedded pictures. These are actually not pictures, but visualizations 
>>> rendered live during the viewing of the document out of a referenced GT 
>>> Example.
>>> 
>>> 
>>> 
>>> Now, GT Examples are likely also new for most people. We introduced them a 
>>> couple of years ago based on the original idea of Markus Gaelli. These are 
>>> a kind of tests that return an object and that can be built out of other 
>>> examples. The nice thing is that they are always executable and testable. 
>>> So, of course, if you see the resulting object,  you can also see the code 
>>> that created it, and if you see the code, you can even execute it live, 
>>> right in place (notice the preview of the second snippet).
>>> 
>>> 
>>> 
>>> Perhaps the most controversial part of GT Examples is that they offer a 
>>> mechanism to define static dependencies via pragmas. Please, let’s leave 
>>> this debate to another occasion, but please also notice that tools can use 
>>> that static information to unfold the code of the referenced method (notice 
>>> the nested code editors).

Re: [Pharo-users] [ann] moldable editor - with expandable elements

[Tudor Girba]

Hi Thierry,

Indeed, you noticed correctly that we stayed away from the code browser.

We found several years ago that Morphic  was too limiting. During the Spotter 
implementation we found ourselves having to construct a mini-Morphic in order 
to do what we wanted to do. With text we had several prototypes for a different 
kind of editing experience, but we hit a wall. The interface from the 
GTInspector is the most rudimentary solution we could put in place, and it is 
there mostly as a placeholder to get over the bridge.

This is why we joined the Bloc project and we focused all our tool development 
effort on it. The goal is to be able to build interfaces that do not yet exist 
and that enable workflows that are radically different. We showed can do that 
once we have an infrastructure, and we will continue to do it until we have a 
full development experience.

We did not start from the experience of writing code explicitly. That is 
because the IDE should encompass all activities including the way we understand 
a system, and we think that focusing on reading is to be left for the previous 
century. So, we started from the inspector and debugger and we are making our 
way towards the writing part.

Writing code is certainly of deep interest to us. However, the system browser 
is the least interesting of the places where we want to write code. That is 
because we want to code against live objects, not against dead text. The main 
use case the system browser is good for is to organize code and to find a 
starting place for getting to a living object. For the rest of the use cases, 
there are other solutions that are better. For example, even with the current 
Playground, we have people spending more time in there than in the code 
browser. That says something given that the Playground is quite bare at the 
moment.

We do not think in terms of tools, but the overall workflows we want to 
support. It’s not a race against features, but a reimagining of what an 
experience can be like. For example, let’s take documentation: right now, both 
producing and consuming documentation happens mostly outside of the 
environment. So, the I in the IDE is failing in this respect. We want to make 
both of these activities more attractive inside the environment and the demo 
you see here is a step in that direction. There is no name for this tool yet 
because we tend to not phrase the problem like that.

Related to other editors, there are indeed WYSWIG tools, but they are typically 
not dynamic. There are viewers that are dynamic, but they tend to not scale 
well and not be editable. There are tools that scale, but they are not too 
visual. And even when there exist some, they are not in an IDE. So, yes, there 
are pieces that already exist, but the way we apply them is novel.

As for syntax highlighting, it is tied to text and attributes but only to the 
extent we wanted it to be. The current implementation is 2k lines of code. In 
comparison, just the core of Rubric is 5.5k. But, the rendering is not related 
to text whatsoever. Word and adornments are just element that conform to a 
layout. So, this means that people can build something else at a much smaller 
costs should they want to.

Cheers,
Doru


> On Aug 27, 2017, at 10:43 AM, Thierry Goubier  
> wrote:
> 
> Hi Doru,
> 
> 2017-08-27 9:24 GMT+02:00 Tudor Girba :
> Hi,
> 
> > On Aug 27, 2017, at 12:06 AM, Thierry Goubier  
> > wrote:
> >
> > Hi Tim,
> >
> > 2017-08-26 23:27 GMT+02:00 Tim Mackinnon :
> > I think you pose some interesting design challenges - but it's worthy of 
> > experimentation.
> >
> > I share Denis' enthusiasm to build something better - but it's true it's 
> > not an easy problem space.
> >
> > I'm a big fan of GTInspector, but sometimes I slide across and lose my 
> > context (not always, and not for all types of problems).
> >
> > I think you may be on the key issue, the loss of context when navigating 
> > through the code. In the 90's, that was called the 'lost in hyperspace' 
> > problem linked with hypertexts and hypermedia.
> >
> > I'm not sure it was ever resolved (I stopped following that research 
> > community during my PhD), apart from considering that google solved it for 
> > the web. At least, this would be the choice made by Newspeak: consider that 
> > the code is like the web, and build a system web browser.
> >
> >
> > For unique extractions - inlining is a no brainer (it's just like code 
> > folding in many editors). For non-unique, maybe something in the gutter 
> > might let you easily flip... I don't know, but I'm not convinced our 
> > current way is always optimal.
> >
> > Agreed. I have changed the way I code to reduce the context needed to 
&g

Re: [Pharo-users] [ann] moldable editor - with expandable elements

[Tudor Girba]

Hi,

> On Aug 27, 2017, at 7:13 PM, Thierry Goubier  
> wrote:
> 
> Hi Doru,
> 
> thanks for the explanation...
> 
> I'll end up with three questions:
> 
> - What makes Bloc different compared to the InterViews and Amulet toolkits? 
> And Unidraw?

Bloc is a low level GUI framework. The widgets and the interaction model for 
building complete applications belongs to a layer above it. This is what Brick 
is supposed to be. We are right now at the level of building widgets and did 
not yet decide on the concrete the interaction model. That is why to make it 
useful, we use the editor embedded inside a Morphic-based interface.

I did not know Amulet, but Interviews and Unidraw I read about more than a 
decade ago and even then I did not manage to get my hands on a working copy. 
Unidraw is a high level component-based engine for building applications that 
bares more similarities with something like Glamour. Nevertheless, I never saw 
Unidraw in practice and from the documentation that is available it is hard to 
distinguish the details, and details matter a lot.

So, perhaps the most important difference is that Bloc works now in Pharo. This 
does not mean that it is the best possible framework, only that it is the best 
we could do. We are confident it is quite good, but it remains to be seen 
whether it will be enough to be practical.


> - Will some of your workflows enables exploration of parallel, 
> non-deterministic programs?

This is certainly an area of interest, although not an easy one. We already 
used logging that collected signals from multiple processes and explored them 
inside GT Inspector, but certainly more is needed.


> - Will we be able to have non-linear execution paths and explorations through 
> examples and documentation?

I am not sure what you mean by execution paths, but when it comes to 
exploration, this is exactly one of the things we are after: there are multiple 
contexts one might want to “consume" code in and most of these are unforeseen. 
For example, showing a method inside a piece of documentation provides an entry 
point that invites a kind of navigation that is orthogonal to the default code 
structure. The whole idea behind humane assessment is that we should craft 
tools to match the current context of interest and this implies new angles of 
exploration, and this is what GT offers. Last year at ESUG I provided some 
examples of such exploration paths:
https://youtu.be/XWOOJa3kEa0?list=PLqvTNJtc942Cs9Qo4ikCGrUNtAw93Q0JA

But, I am not sure I actually addressed your question.

Cheers,
Doru

> Regards,
> 
> Thierry
> 
> 2017-08-27 13:37 GMT+02:00 Tudor Girba :
> Hi Thierry,
> 
> Indeed, you noticed correctly that we stayed away from the code browser.
> 
> We found several years ago that Morphic  was too limiting. During the Spotter 
> implementation we found ourselves having to construct a mini-Morphic in order 
> to do what we wanted to do. With text we had several prototypes for a 
> different kind of editing experience, but we hit a wall. The interface from 
> the GTInspector is the most rudimentary solution we could put in place, and 
> it is there mostly as a placeholder to get over the bridge.
> 
> This is why we joined the Bloc project and we focused all our tool 
> development effort on it. The goal is to be able to build interfaces that do 
> not yet exist and that enable workflows that are radically different. We 
> showed can do that once we have an infrastructure, and we will continue to do 
> it until we have a full development experience.
> 
> We did not start from the experience of writing code explicitly. That is 
> because the IDE should encompass all activities including the way we 
> understand a system, and we think that focusing on reading is to be left for 
> the previous century. So, we started from the inspector and debugger and we 
> are making our way towards the writing part.
> 
> Writing code is certainly of deep interest to us. However, the system browser 
> is the least interesting of the places where we want to write code. That is 
> because we want to code against live objects, not against dead text. The main 
> use case the system browser is good for is to organize code and to find a 
> starting place for getting to a living object. For the rest of the use cases, 
> there are other solutions that are better. For example, even with the current 
> Playground, we have people spending more time in there than in the code 
> browser. That says something given that the Playground is quite bare at the 
> moment.
> 
> We do not think in terms of tools, but the overall workflows we want to 
> support. It’s not a race against features, but a reimagining of what an 
> experience can be like. For example, let’s take documentation: right now, 
> both producing and cons

Re: [Pharo-users] [ann] moldable editor - with expandable elements

[Tudor Girba]

Hi Denis,

Thanks for the feedback!

As I mentioned, this is a pre-alpha :). Our main focus was on exploring that 
the design works in breadth. There are indeed, detailed issues that do not work 
yet, and there are edge cases for navigation and insertion/deletion that are 
still open issues.

In Bloc we intentionally have not focused on error catching yet. So, right now 
when there is an error during layout or rendering, Bloc can get in a funny 
state. You can reset Bloc with:
BlUniverse reset

The code works fine in Pharo 7.0. I just tried the following:

1. wget -O- get.pharo.org/alpha+vm | bash
2.
Iceberg enableMetacelloIntegration: true.
Metacello new
   baseline: 'GToolkit';
   repository: 'github://feenkcom/gtoolkit/src';
   load
3. 
'./pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' 
asFileReference

Cheers,
Doru



> On Aug 29, 2017, at 11:04 AM, Denis Kudriashov  wrote:
> 
> Hi
> 
> I have bad feedback. I guess work is still in progress.
> 
> So basic cursor navigation is still not working fine:
> - sometimes cmd+arrow up is not working and cursor disappears.
> - scrolling feels slow and not smooth.
> After attempt to edit text (just press key) I got assertion failures about 
> some layout problems. And after reopening inspector the bloc pillar tab was 
> empty.
> 
> When you are expecting stable version?
> Should it works better in "native" Bloc window (without morphic)? And how to 
> open example this way?
> 
> Also it not loads well in Pharo 7 and not working there. 
> My feedback from Pharo 6 on MacOS
> 
> 2017-08-26 1:03 GMT+02:00 Tudor Girba :
> Hi,
> 
> We are really pleased to announce another major advancement in the 
> development of the moldable editor, and most of it was enabled because of one 
> new feature: expandable elements. We think this will impact significantly our 
> day to day interactions.
> 
> To exemplify what we mean, we will make use of two more alpha projects that 
> we did not announce yet: GT Documenter (a set of documentation tools based on 
> Pillar and GT Examples) and GT Mondrian (the graph visualization engine), 
> both of which are being implemented in Bloc.
> 
> Please take a look at the following pictures showing the documentation Pillar 
> file that ships together with GT Mondrian. What stands out are the two 
> embedded pictures. These are actually not pictures, but visualizations 
> rendered live during the viewing of the document out of a referenced GT 
> Example.
> 
> 
> 
> Now, GT Examples are likely also new for most people. We introduced them a 
> couple of years ago based on the original idea of Markus Gaelli. These are a 
> kind of tests that return an object and that can be built out of other 
> examples. The nice thing is that they are always executable and testable. So, 
> of course, if you see the resulting object,  you can also see the code that 
> created it, and if you see the code, you can even execute it live, right in 
> place (notice the preview of the second snippet).
> 
> 
> 
> Perhaps the most controversial part of GT Examples is that they offer a 
> mechanism to define static dependencies via pragmas. Please, let’s leave this 
> debate to another occasion, but please also notice that tools can use that 
> static information to unfold the code of the referenced method (notice the 
> nested code editors).
> 
> A side note: if you look closer at the list with three items at the top of 
> the Tutorial section, you will notice numbering next to #. That is actually 
> syntax highlighting and so is the mechanism that embeds the expandable 
> elements. It’s really cool.
> 
> Taking step back, when we introduced the editor a few weeks ago, we called it 
> moldable because we said we can make it take different shapes easily. GT 
> Documenter with everything you see in the above screenshots has currently 
> ~500 lines of code, and all this while still having an editor that is highly 
> scalable.
> 
> We think that Bloc and Brick will change dramatically face of Pharo and now 
> we can start to get a glimpse of what is possible. For example, the use case 
> presented above is more than a technical tool, and we think this will change 
> both the way we write documentation and the way we consume it.
> 
> All these will be presented at ESUG both during presentations and at the 
> Innovation Awards competition. In the meantime, those that want to play with 
> it can execute the following in both Pharo 6.1 and Pharo 7.0:
> 
> Iceberg enableMetacelloIntegration: true.
> Metacello new
>baseline: 'GToolkit';
>repository: 'github://feenkcom/gtoolkit/src';
>load.
> 
> And then inspect:
> './pharo-local/iceberg

Re: [Pharo-users] [ann] moldable editor - with expandable elements

[Tudor Girba]

> On Aug 29, 2017, at 12:52 PM, Denis Kudriashov  wrote:
> 
> The code works fine in Pharo 7.0. I just tried the following:
> 1. wget -O- get.pharo.org/alpha+vm | bash
> 
> Ah, sorry. I always forgot update.


No problem. I am happy that it works :).

Doru

>  
> 2.
> Iceberg enableMetacelloIntegration: true.
> Metacello new
>baseline: 'GToolkit';
>repository: 'github://feenkcom/gtoolkit/src';
>load
> 3.
> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' 
> asFileReference
> Cheers,
> Doru
> 
> 2017-08-29 11:32 GMT+02:00 Tudor Girba :
> Hi Denis,
> 
> Thanks for the feedback!
> 
> As I mentioned, this is a pre-alpha :). Our main focus was on exploring that 
> the design works in breadth. There are indeed, detailed issues that do not 
> work yet, and there are edge cases for navigation and insertion/deletion that 
> are still open issues.
> 
> In Bloc we intentionally have not focused on error catching yet. So, right 
> now when there is an error during layout or rendering, Bloc can get in a 
> funny state. You can reset Bloc with:
> BlUniverse reset
> 
> The code works fine in Pharo 7.0. I just tried the following:
> 
> 1. wget -O- get.pharo.org/alpha+vm | bash
> 2.
> Iceberg enableMetacelloIntegration: true.
> Metacello new
>baseline: 'GToolkit';
>repository: 'github://feenkcom/gtoolkit/src';
>load
> 3.
> './pharo-local/iceberg/feenkcom/gtoolkit/doc/mondrian/index.pillar' 
> asFileReference
> 
> Cheers,
> Doru
> 
> 
> 
> > On Aug 29, 2017, at 11:04 AM, Denis Kudriashov  wrote:
> >
> > Hi
> >
> > I have bad feedback. I guess work is still in progress.
> >
> > So basic cursor navigation is still not working fine:
> > - sometimes cmd+arrow up is not working and cursor disappears.
> > - scrolling feels slow and not smooth.
> > After attempt to edit text (just press key) I got assertion failures about 
> > some layout problems. And after reopening inspector the bloc pillar tab was 
> > empty.
> >
> > When you are expecting stable version?
> > Should it works better in "native" Bloc window (without morphic)? And how 
> > to open example this way?
> >
> > Also it not loads well in Pharo 7 and not working there.
> > My feedback from Pharo 6 on MacOS
> >
> > 2017-08-26 1:03 GMT+02:00 Tudor Girba :
> > Hi,
> >
> > We are really pleased to announce another major advancement in the 
> > development of the moldable editor, and most of it was enabled because of 
> > one new feature: expandable elements. We think this will impact 
> > significantly our day to day interactions.
> >
> > To exemplify what we mean, we will make use of two more alpha projects that 
> > we did not announce yet: GT Documenter (a set of documentation tools based 
> > on Pillar and GT Examples) and GT Mondrian (the graph visualization 
> > engine), both of which are being implemented in Bloc.
> >
> > Please take a look at the following pictures showing the documentation 
> > Pillar file that ships together with GT Mondrian. What stands out are the 
> > two embedded pictures. These are actually not pictures, but visualizations 
> > rendered live during the viewing of the document out of a referenced GT 
> > Example.
> >
> > 
> >
> > Now, GT Examples are likely also new for most people. We introduced them a 
> > couple of years ago based on the original idea of Markus Gaelli. These are 
> > a kind of tests that return an object and that can be built out of other 
> > examples. The nice thing is that they are always executable and testable. 
> > So, of course, if you see the resulting object,  you can also see the code 
> > that created it, and if you see the code, you can even execute it live, 
> > right in place (notice the preview of the second snippet).
> >
> > 
> >
> > Perhaps the most controversial part of GT Examples is that they offer a 
> > mechanism to define static dependencies via pragmas. Please, let’s leave 
> > this debate to another occasion, but please also notice that tools can use 
> > that static information to unfold the code of the referenced method (notice 
> > the nested code editors).
> >
> > A side note: if you look closer at the list with three items at the top of 
> > the Tutorial section, you will notice numbering next to #. That is actually 
> > syntax highlighting and so is the mechanism that embeds the expandable 
> > elements. It’s really cool.
> >
> > Taking step back, when we in

Re: [Pharo-users] [Pillar][editor][Pharo 6.1] How do I get to work 'Transform code snippets to new format'?

[Tudor Girba]

Hi,

Indeed, this depends on PetitIslands. But, anyway, this feature was a 
transformation for migrating old Pier line-based sources (starting with =) to 
newer Pillar-based one (with [[[ ]]]). I will remove this feature because it is 
not really needed anymore.

Cheers,
Doru


> On Sep 1, 2017, at 12:00 PM, H. Hirzel  wrote:
> 
> Hello
> 
> In a pristine Pharo 6.0/6.1 image I installed Pillar [1]. The editor
> for Pillar code works fine. It includes a menu entry
> 
> 'Transform code snippets to new format'
> 
> If I choose this entry a debug window appears [2]. It seems that I
> need to install an additional package.
> 
> Which one and how do I do that?
> 
> Thank you in advance
> 
> Hannes
> 
> 
> 
> 
> 
> 
> 
> 
> 
> [1] Not through the catalog but with
> 
>  Metacello new
>  smalltalkhubUser: 'Pier' project: 'Pillar';
>  configuration: 'Pillar';
>  version: #stable;
>  load.
> 
> This version comes with a Pillar editor.
> The version in the catalog seems to be older and does not contain a
> Pillar editor.
> 
> 
> 
> [2] PPActionParser(Object)>>doesNotUnderstand: #island
> GTOldCodeSnippet>>start
> [ :class :parser |
> parser setParser: (parser perform: parser children first name).
> parser productionNames
>   keysAndValuesDo:
>   [ :key :value | (parser instVarAt: key) setParser: (parser 
> perform:
> value) ] ] in GTOldCodeSnippet class(PPCompositeParser
> class)>>newStartingAt:
> [ :assoc | aBlock value: assoc key value: assoc value ] in
> IdentityDictionary(Dictionary)>>keysAndValuesDo:
> [ :each | each ifNotNil: [ aBlock value: each ] ] in
> IdentityDictionary(Dictionary)>>associationsDo:
> Array(SequenceableCollection)>>do:
> IdentityDictionary(Dictionary)>>associationsDo:
> IdentityDictionary(Dictionary)>>keysAndValuesDo:
> GTOldCodeSnippet class(PPCompositeParser class)>>newStartingAt:
> GTOldCodeSnippet class(PPCompositeParser class)>>new
> [ :rub |
> | newContents |
> newContents := GTOldCodeSnippet new parse: self contents.
> self
>   ensureDelete;
>   writeStreamDo: [ :s | s nextPutAll: newContents ].
> rub update ] in FileReference>>gtInspectorPillarIn:
> BlockClosure>>glamourValueWithArgs:
> GLMGenericAction(GLMAction)>>actOn:
> GLMGenericAction(GLMAction)>>morphicActOn:
> [ | selArgCount |
> "show cursor in case item opens a new MVC window"
> (selArgCount := selector numArgs) = 0
>   ifTrue: [ target perform: selector ]
>   ifFalse: [ selArgCount = arguments size
>   ifTrue: [ target perform: selector withArguments: 
> arguments ]
>   ifFalse: [ target perform: selector withArguments: 
> (arguments
> copyWith: evt) ].
>   self showShortcut ].
> self changed ] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent:
> BlockClosure>>ensure:
> CursorWithMask(Cursor)>>showWhile:
> ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent:
> ToggleMenuItemMorph(MenuItemMorph)>>mouseUp:
> ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp:
> 
> 

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

"Innovation comes in the least expected form. 
That is, if it is expected, it already happened."

[Pharo-users] [ann] moldable editor - documenter and examples without pragma magic

[Tudor Girba]

Hi,

When we announced the GT Documenter as an application for the moldable editor, 
one of the remarks was that GT Examples implementation relies too much on 
pragma magic.

We are now happy to announce that this is no longer the case because Andrei did 
a great job and rebuilt examples without the need for static pragmas for 
specifying dependencies.

So, now we can example dependencies simply through normal calls:

emptyView

^ GtMondrian new

twoNodes

view := self emptyView
view nodes with: {1 . 2}

... and the engine can figure out the static dependencies. This means that 
examples can be used both as plain unary methods, and as replacement for tests. 
We think this should address the worry of examples being too heavy (the current 
implementation is ~350 lines).

With a bit of extra effort, we also adapted GT Documenter to expand the example 
dependencies as seen below. This means that examples can now be used directly 
as units of documentation as well.

We think this is significant.



Cheers,
The feenk team


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

"We are all great at making mistakes."

Re: [Pharo-users] How to create a minimal image ?

[Tudor Girba]

+1.

Also, there can be different UIs that one might want to choose from (for 
example, Bloc and Morphic) without having both loaded at the same time.

Cheers,
Doru


> On Aug 31, 2017, at 8:20 PM, Stephane Ducasse  wrote:
> 
> We are talking about **Pharo Core** and we will reduce it even more.
> Then you can load the UI.
> And no UI is not the very essence of Smalltalk.
> You can connect remotely to a live kernel and program it and this is
> still a live system.
> 
> On Mon, Aug 28, 2017 at 1:33 PM, Dimitris Chloupis
>  wrote:
>> for me Pharo and GUI go hand in hand, I cannot imagine Pharo without GUI. I
>> also despise the command line. Plus once you remove the GUI you kill the
>> very essence of Smalltalk.
>> 
>> But if that is what you(you as all people who support this) like and need,
>> that's your choice and I respect that.
>> 
>> Even back in the 80s when almost everything was command lines , I was
>> drooling over Amiga's 500 beautiful coloured GUIs. It started my fascination
>> with computer graphics and later 3d graphics and sound.
>> 
>> So me and the GUI are very old friends and we go hand in hand :)
>> 
>> Of course I understand if we want to go super minimal the GUI has to go
>> together with many other things that make Pharo what it is. But I dont care
>> for such extremes. I just wanted to reduce the fat.
>> 
>> On Mon, Aug 28, 2017 at 2:24 PM Pavel Krivanek 
>> wrote:
>>> 
>>> What do you expect from such minimal image? Because we can produce several
>>> intermediate steps on the way to the standard full Pharo image
>>> (BaselineOfMorphicCore, BaselineOfMorphic, BaselineOfUI,
>>> BaselineOfBasicTools...)
>>> 
>>> -- Pavel
>>> 
>>> 2017-08-28 13:17 GMT+02:00 Dimitris Chloupis :
 
 oh , then its not what I am thinking as minimal image. Pity, oh well , I
 will wait for bootstrap to mature then :)
 
 On Mon, Aug 28, 2017 at 2:09 PM Pavel Krivanek 
 wrote:
> 
> The minimal image is headless image without any GUI. It is useless to
> try to open it this way.
> 
> -- Pavel
> 
> 2017-08-28 13:03 GMT+02:00 Dimitris Chloupis :
>> 
>> hmm does not work for me, it open the icon of pharo on macos sierra
>> dock and it stays there doing nothing
>> right clicking on it and choosing quit does nothing, so I am have to
>> use force quit to make it close
>> 
>> I have downloaded pharo 6.1 from the website, default download, 32 bit,
>> minimal 32 bit image. I drag and drop image on top of pharo.
>> 
>> On Mon, Aug 28, 2017 at 10:29 AM Pavel Krivanek
>>  wrote:
>>> 
>>> 2017-08-26 19:31 GMT+02:00 Dimitris Chloupis :
 
 I remember that the website used to link to a minimal image download
 but it does not seem there is one anymore
 
 Is still minimal image maintained ?
>>> 
>>> 
>>> yes, as part of the bootstrap process
>>> 
 
 Are there ways to make a image minimal ?
>>> 
>>> 
>>> it is created in bootstrap/scripts/build.sh under name
>>> Pharo7.0-metacello-* and saved on files.pharo.org as
>>> http://files.pharo.org/image/70/latest-minimal-32.zip or
>>> http://files.pharo.org/image/70/latest-minimal-64.zip
>>> 
>>> So you do not need to do it by yourself.
>>> 
>>> -- Pavel
> 
> 
>>> 
>> 
> 

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

"From an abstract enough point of view, any two things are similar."

Re: [Pharo-users] [Pharo-dev] Scraping HTML chapter 2 (soon chapter 3 coming)

[Tudor Girba]

Nice work!

Doru


> On Sep 27, 2017, at 9:25 AM, Stephane Ducasse  wrote:
> 
> I came with the idea of this booklet thank to Peter Kenny that kindly
> answered a question on the Pharo mailing-list.
> To help, Peter showed to a Pharoer how to scrap a web site
> using XPath. In addition, some years ago
> I was maintaining Soup a scraping framework because I was scraping
> magic web sites and I wanted an application to manage my magic cards.
> Since then I always wanted to try XPath and in addition I wanted to
> offer this booklet to Peter. Why because I asked Peter
> if he would like to write something and he told that he was at a great
> age where he would not take any commitment.
> I realised that I would like to get as old as him and be able to hack
> like a mad in Pharo with new technology.
> So this booklet is a gift to Peter, a great and gentle Pharoer.
> 
> Stef
> 

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

"Being happy is a matter of choice."

Re: [Pharo-users] Bloc Space within a Space

[Tudor Girba]

Hi,

Indeed, this was a focus since the very beginning.

However, at present time, it is not possible to do it in practice out of the 
box and you cannot control the cursor either. This is something we still need 
to add, but it is definitely a top interest to get this working.

Cheers,
Doru


> On Sep 24, 2017, at 9:33 AM, Stephane Ducasse  wrote:
> 
> Hi sean
> 
> normally with bloc you should be able to build the expose mode on mac os X.
> with multiple little worlds showing windows inside and to control all
> the events.
> It was the goal of alain now I do not know but it should
> Stef
> 
> BlUniverse
> 
> I am the lowest level in Bloc.
> My responsibility is to manage the low-level services such as managing
> windows, event queue and the drawing synchronization.
> 
> My main responsibility is to manage and to keep in sync the opened Spaces.
> 
> I am the interface used to create/delete window.
> To achieve that, i use the notion of Host (see: BlHost).
> 
> Users can choose a preferable host. In order to do that a universe
> must be stopped first.
> Example:
> 
> universe stop.
> universe preferableHost: MyHost new.
> universe start.
> 
> BLSpaceManager
> 
> I am a Universe space manager.
> 
> I contain Bloc spaces, can add or remove them. I am also responsible
> for sending pulses(tick) messages to spaces I know.
> 
> I am used by Universe in order to provide support of multiple spaces
> within the Universe.
> 
> - addSpace: add a space
> - removeSpace: remove a given space
> - clear close all spaces
> - pulse send pulse message to all spaces
> 
>   One simple example is simply gorgeous.
> 
> Internal Representation and Key Implementation Points.
> 
>Instance Variables
> spaces: 
> 
> 
>Implementation Points
> 
> 
> 
> On Sun, Sep 24, 2017 at 3:49 AM, Sean P. DeNigris  
> wrote:
>> Pharo Smalltalk Users mailing list wrote
 But how to drive it? e.g. simulate events
>>> 
>>> ok, so we agree here. Bloc is done in that perspective.
>>> For now, you have to implement your own BlocSpace with an adequate
>>> #processEvents method,
>>> your can also implement your own main loop manager (polymorphic with
>>> BlMainLoopManager).
>> 
>> Given the flurry of Bloc development, are we able (or any closer) today to
>> simulate a Bloc world/space/whatever-the-lingo-is, taking full control over
>> the hand, events, etc? For years I've dreamed of being able to mock/stub out
>> all the dependencies and have full control over a world within a world.
>> There seemed to be agreement in principle, but it always seemed "just around
>> the bend". I loaded Bloc in latest Pharo to play around, but am not quite
>> sure if this is yet possible.
>> 
>> Thanks!
>> 
>> 
>> 
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>> 
> 

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

“The smaller and more pervasive the hardware becomes, the more physical the 
software gets."

Re: [Pharo-users] [Pharo-dev] Videos ESUG17 Day1 online

[Tudor Girba]

Thanks, Marcus!

Doru


> On Oct 11, 2017, at 9:50 AM, Marcus Denker  wrote:
> 
> Hi,
> 
> The videos of the first day are online:
> 
> https://www.youtube.com/playlist?list=PLJ5nSnWzQXi_THfKwhzxFwbXy00YTi0uv
> 
> 
> More coming soon.
> 
>   Marcus
> 
> 

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

"We can create beautiful models in a vacuum.
But, to get them effective we have to deal with the inconvenience of reality."

Re: [Pharo-users] CodeCity like visualization in Linux

[Tudor Girba]

CodeCity only works in Pharo 3 (or maybe also 4).

Doru


> On Oct 25, 2017, at 1:38 AM, Rafael Luque  
> wrote:
> 
> Hi all,
> 
> I'm working on an introductory talk about Pharo for a software craftsmanship 
> local meetup.
> 
> The presentation will be mainly driven by demos and I'd like to show a 
> CodeCity-like visualization. I've been able to load it in Pharo 5, but it get 
> an error when select the "City" tag in GTInspector. It seems that NBOpenGL 
> does not work in Linux. 
> 
> Do you know any way to make it work in Linux?
> 
> Thank you.
> ‌

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

"Presenting is storytelling."

Re: [Pharo-users] CodeCity like visualization in Linux

[Tudor Girba]

Hi,

Indeed, the image was for Mac, but unfortunately I do not know if it works on 
Linux.

But, for your talk, there are other cool things that you can show in the latest 
Moose. If you are interested, please contact me directly.

Cheers,
Doru


> On Oct 25, 2017, at 9:39 AM, Rafael Luque  
> wrote:
> 
> Thank you for your help Tudor.
> 
> I'm trying with the CodeCity image I've downloaded from your post 
> (http://www.humane-assessment.com/blog/communicating-changes-in-pharo-3-0) 
> and I get the error "MessageNotUnderstood: receiver of "platformId" is nil" 
> in the NBMacGLContextDriver class>>supportsCurrentPlatform method.
> 
> By this reason I thought it only works on Mac or maybe I must previously 
> configure something to get the NativeBoost working on Linux.
> 
> Thank you.
> 
> 
> 
> ‌
> 
> 2017-10-25 9:02 GMT+02:00 Tudor Girba :
> CodeCity only works in Pharo 3 (or maybe also 4).
> 
> Doru
> 
> 
> > On Oct 25, 2017, at 1:38 AM, Rafael Luque  
> > wrote:
> >
> > Hi all,
> >
> > I'm working on an introductory talk about Pharo for a software 
> > craftsmanship local meetup.
> >
> > The presentation will be mainly driven by demos and I'd like to show a 
> > CodeCity-like visualization. I've been able to load it in Pharo 5, but it 
> > get an error when select the "City" tag in GTInspector. It seems that 
> > NBOpenGL does not work in Linux.
> >
> > Do you know any way to make it work in Linux?
> >
> > Thank you.
> > ‌
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Presenting is storytelling."
> 
> 
> 

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

"Being happy is a matter of choice."

Re: [Pharo-users] Territorial loading problems & alternative ways of loading data for making a choropleth map

[Tudor Girba]

You can directly use the Roassal presentation


gtInspectorExtension: composite

composite roassal2
title: ‘...'
initializeView: [ YourViewOrBuilder ];
painting: [ :yourViewOrBuilder | …  ]

Doru

> On Oct 25, 2017, at 5:57 AM, Hernán Morales Durand  
> wrote:
> 
> 2017-10-24 15:24 GMT-03:00 Offray Vladimir Luna Cárdenas
> :
>> Gracias Hernán!
>> 
> 
> No problema :)
> 
>> This is working fine. I would like to put the displayed map inside the
>> GT playground right panel, to get something similar to what you get when
>> you execute "RTMapLocationExample new exampleSeismOnEarth" from a
>> playground. Do you have any planned support for that?
>> 
> 
> I know this should be as easy as adding a
>  pragma
> 
> gtInspectorViewIn: composite
>
> 
>composite morph
>title: 'Territorial Map';
>display: [ view build ]
> 
> but still I have to investigate how to connect a RTView or TRMorph
> with GT inspector
> 
>> I could try to use some similar approach to the one I take on the Panama
>> Papers choropleth map [1][2] to export some Territorial data for
>> visualizations in a light format (120kb file example at: [3]), if you're
>> interested.
>> 
>> [1] http://mutabit.com/offray/blog/en/entry/panama-papers-1
>> [2] http://mutabit.com/repos.fossil/panama-papers/doc/tip/index.html
>> [3] http://mutabit.com/repos.fossil/panama-papers/doc/tip/territories.ston
>> 
> 
> Super! It would be nice to see usage in other scenarios!
> Let me know how it goes.
> 
> Cheers,
> 
> Hernán
> 
>> Cheers,
>> 
>> Offray
>> 
>> 
>> On 23/10/17 23:21, Hernán Morales Durand wrote:
>>> Hola Offray,
>>> 
>>> I tried loading in Windows 8.1 and it loads fine using:
>>> 
>>> Metacello new
>>>smalltalkhubUser: 'hernan' project: 'Territorial';
>>>configuration: 'Territorial';
>>>version: #bleedingEdge;
>>>load.
>>> 
>>> Then load TerritorialData-AMCharts-HernanMoralesDurand.2 from the 
>>> repository.
>>> 
>>> I published some "fixes" related to Spec and Roassal. (I have to
>>> review them because I'm porting other packages to Pharo 6.1, but it
>>> should work for displaying maps).
>>> 
>>> The following expression displays a window with Colombia departments:
>>> 
>>> TerritorialAMChartsMapsProvider viewHighResCountry: 'Colombia'
>>> 
>>> For a choropleth with a heatmap or centroids have a look at how I did
>>> it in PhyloclassTalk in SmalltalkHub, again I should update it to work
>>> in Pharo 6.1.
>>> 
>>> Cheers,
>>> 
>>> Hernán
>>> 
>>> 
>>> 
>>> 2017-10-23 22:59 GMT-03:00 Offray Vladimir Luna Cárdenas
>>> :
 Hi,
 
 I would like a choropleth map of Colombian departments [1]. The first
 approach would be to use Territorial, but loading it is not working on
 Pharo 6.1 (used on Manjaro Linux): It doesn't appears in the Catalog,
 Gopher load gives me: "XMLFileException: File does does not exist:
 /home/offray/Programas/Pharo/6.1a/Dev24/territorial_files/fao/fao_country_names.xml"
 and loading Monticello bleeding edge gives me "FileDoesNotExist: File @
 /home/offray/Programas/Pharo/6.1a/Dev24/territorial_files/opengeocode/wc-ASCII.csv".
 There is another way to make such choropleth map?
 
 [1] https://en.wikipedia.org/wiki/Departments_of_Colombia
 
 Thanks,
 
 Offray
 
 
 
>> 
>> 
>> 
> 

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

"Problem solving efficiency grows with the abstractness level of problem 
understanding."

Re: [Pharo-users] Annual online conference?

[Tudor Girba]

Nice idea, indeed.

Doru


> On Oct 26, 2017, at 10:18 AM, Marcus Denker  wrote:
> 
> That’s a nice idea! 
> 
> I will check how they did it and we should see if that makes sense in the 
> future.
> (for Pharo Days)
> 
>   Marcus
> 
>> On 25 Oct 2017, at 23:17, PAUL DEBRUICKER  wrote:
>> 
>> Laravel.com is a PHP web framework.  
>> 
>> 
>> Their community organizes an online conference: https://laracon.net/2017
>> 
>> 
>> Seems like it could be worthy of mimicking in the Smalltalk community.
>> 
> 
> 

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

"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."

Re: [Pharo-users] [Pharo-dev] [ANN] Iceberg 0.6.2 backported to Pharo 6.1

[Tudor Girba]

Great work!

Doru


> On Oct 27, 2017, at 11:36 AM, Esteban Lorenzano  wrote:
> 
> Hi,
> 
> I backported lastest Iceberg version to Pharo 6.1 to allow people to benefit 
> for latest changes. 
> This version has an important amount of tweak and fixes, but most important 
> is the inclusion of tonel file format (this is default for Pharo 7.0, 
> optional for Pharo 6.1) and introduces a file-per-class format. 
> The advantages of this format has everything to do with the speed of access 
> (is easier to reconstruct a package like) and the space on disk (methods are 
> usually small but minimum space in disk is usually 4k so we waste a lot of 
> space). Is also a better format for SSD disks.
> 
> To backport Iceberg 0.6.2 I also needed to backport latest version of 
> Metacello, so Pharo 6.1 and Pharo7+ users now also have the latest version of 
> it available :)
> 
> cheers!
> Esteban
> 
> 
> 
> 
> 

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

"We cannot reach the flow of things unless we let go."

Re: [Pharo-users] LiteratureResearcher - where graphs, PDFs, and BibTex happily live together

[Tudor Girba]

Really nice work!

Indeed, the PDF integration can be quite interesting to people.

Doru


> On Nov 2, 2017, at 6:08 PM, Stephane Ducasse  wrote:
> 
> Hi manuel
> 
> this is super cool :)
> Could you describe how you did the pdf integration?
> And yes please package it :)
> I want to try it.
> 
> Stef
> 
> On Wed, Nov 1, 2017 at 10:16 PM, Manuel Leuenberger
>  wrote:
>> Hi everyone,
>> 
>> I was experimenting in the last few weeks with my take on literature
>> research. For me, the corpus of scientific papers form an interconnected
>> graph, not those plain lists and tables we keep in our bibliographies. So,
>> here is the first prototype that has Google Scholar integration for search,
>> can fetch PDFs from IEEE and ACM, extracts metadata from PDFs - all this
>> results in hyperlinked PDFs!
>> 
>> See a demo here: https://youtu.be/EcK3Pt_WnEw
>> Also slides from the SCG seminar here:
>> http://scg.unibe.ch/download/softwarecomposition/2017-10-31-Leuenberger-ILE.pdf
>> 
>> I plan on packaging it, so that those who are interested can check it out
>> themselves (help wanted!). Currently, it only works on macOS.
>> 
>> What do you think of my approach? Which use cases should be added?
>> 
>> Cheers,
>> Manuel
>> 
> 

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

"Be rather willing to give than demanding to get."

Re: [Pharo-users] CodeCity in Pharo 6?

[Tudor Girba]

It’s not maintained.

Doru


> On Nov 4, 2017, at 8:46 PM, Peter Uhnák  wrote:
> 
> Hi,
> 
> I've tried installing Code City in Pharo6, and apart from the fixing the 
> Configurations, there is a dependency on NBOpenGL, which doesn't play well 
> with P6 ... complains about missing NB (which is understandable considering 
> NB was replaced with UFFI)...
> 
> So the question is... is this project still maintained?
> 
> Thanks,
> Peter

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

“Software has no shape. Actually, it has no one shape. It has many."

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

[Tudor Girba]

Hi,

As shown at ESUG, GT Documenter offers an advanced viewer (and editor) for 
Pillar working on top of Bloc.

You can get it by loading:

Iceberg enableMetacelloIntegration: true.
Metacello new
   baseline: 'GToolkit';
   repository: 'github://feenkcom/gtoolkit/src';
   load.

For example, you can then inspect:
'PATH_TO_ICEBERG/feenkcom/gtoolkit/doc/transcript/index.pillar’ asFileReference

Cheers,
Doru


> On Nov 10, 2017, at 12:58 PM, H. Hirzel  wrote:
> 
> A note:
> 
> Tudor Girba wrote:
> Fri, Aug 25, 2017 at 1:31 PM
> Reply-To: Any question about pharo is welcome 
> To: Any question about pharo is welcome 
> 
> Hi,
> 
> As mentioned in an announcement about 10 days ago, we are building a
> Pillar editor with inline viewing abilities in Bloc. Here is how it
> looked like. Please note the embedded picture. We continued working on
> it since then and we will probably announce the next version this
> weekend:
> 
> 
> Maybe there is now enough progress to do simple presentations in Bloc?
> 
> 
> On 11/10/17, H. Hirzel  wrote:
>> Hello
>> 
>> In the thread 'including Pillar in Pharo image by default' it was
>> suggested by Stephane Ducasse to include a subset of Pillar in the
>> Pharo image[1] .
>> 
>> I'd like to extend that proposal a little bit it in order  to do very
>> simple presentations. This should allow to describe at least part of
>> the slides used in the MOOC course [3].
>> 
>> This will be  _a possible_ solution to the question  brought up in the
>> thread 'Writing "powerpoint" like presentations in Pharo?'.
>> 
>> Another use is to write instructions with executable content within
>> the image ("Assistants").
>> 
>> So below is the a proposal for a Pillar syntax _subset_ for class
>> comments and _simple_ presentations.
>> The numbering scheme follows the 'Pillar syntax cheat sheet' [2]
>> 
>> 
>> 
>> 
>> MINI PILLAR SYNTAX (a subset of Pillar)
>> 
>> 1. Headers
>> 
>>!Header 1
>>!!Header 2
>>!!!Header 3
>> 
>> 
>> 2. Lists
>> 
>>- Unordered List
>># Ordered list
>> 
>> 
>> 
>> 5. Emphasis
>> 
>>""bold""
>> 
>> 
>> 6. Code blocks
>> 
>> [[[
>> Transcript show: 'Hello World'.
>> \]]]
>> 
>> 
>> 9. Annotation
>> 
>> ${slide:title=About Pharo}$
>> 
>> 
>> 
>> 
>> Next week I plan to implement the rendering of this 'Mini Pillar' in
>> Morphic using the Morphic API subset that works in Pharo and Squeak.
>> 
>> A renderer using Bloc would also be nice. [4]
>> 
>> Comments, suggestions, code snippets and other help is welcome.
>> 
>> Regards
>> Hannes
>> 
>> 
>> 
>> 
>> --
>> [1] Pillar subset for class comments
>> 
>> Stephane Ducasse
>> Fri, Aug 11, 2017 at 7:09 PM
>> To: Any question about pharo is welcome 
>> 
>> Tx cyril
>> 
>> For class comment I image that we want
>> 
>> !
>> 
>> -
>> -
>> *url*
>> and bold
>> [[[
>> 
>> ]]]
>> 
>> Did I miss something.
>> 
>> Stef
>> 
>> 
>> 
>> 
>> 
>> --
>> [2]
>> http://pillarhub.pharocloud.com/hub/pillarhub/pillarcheatsheet
>> --
>> 
>> 
>> 1. Headers
>> 
>>!Header 1
>>!!Header 2
>>!!!Header 3
>>Header 4
>>!Header 5
>>!!Header 6
>> 
>> 2. Lists
>> 
>>- Unordered List
>># Ordered list
>> 
>> 3. Table
>> 
>>|! Left |! Right |! Centered
>>|{Left |}Right| Centered
>> 
>> 
>> 4. Description
>> Note
>> on a new line
>> 
>>;head
>>:item
>> 
>> 
>> 5. Emphasis
>> 
>>""bold""
>>''italic''
>>--strikethrough--
>>__underscore__
>>==inline code==
>>@@subscript@@
>>^^sub-script^^
>> 
>> 6. Code blocks
>> 
>> [[[lab­el=­hel­loS­cri­pt|­cap­tio­n=

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

[Tudor Girba]

Hi,


> On Nov 10, 2017, at 9:20 PM, Sean P. DeNigris  wrote:
> 
> Tudor Girba-2 wrote
>> As shown at ESUG, GT Documenter offers an advanced viewer (and editor) for
>> Pillar working on top of Bloc.
> 
> Two questions after playing with it:
> 1. Can one save a live-edited file?

The saving action is not implemented yet.

> 2. Is it possible to make the markup codes invisible? That would seem more
> appropriate e.g. in a read-only context.

That would be another renderer, but it is not difficult to build. That is 
something we’ll do soon.

Cheers,
Doru

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

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

"Beauty is where we see it."

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

[Tudor Girba]

ach for a good 
> documentation toolkit for now is on Spec and creating custom syntax 
> highlighters with SmaCC[3], that is well documented and works today.
> [3] 
> https://medium.com/@juliendelplanque/hacking-a-simple-syntactic-highlighter-around-specs-textmodel-44ba2e2b1ab9
> I understand that community is trying its best, but expressing how current 
> offerings are not mature and constructive criticism can help on that. At the 
> moment my feeling is that if you want to try the new shinny alpha stuff from 
> GT Documenter, you will need to be prepared for a lot of frustration and 
> silence.
> 
> Cheers,
> 
> Offray
> 
> On 10/11/17 12:41, Tudor Girba wrote:
>> Hi,
>> 
>> As shown at ESUG, GT Documenter offers an advanced viewer (and editor) for 
>> Pillar working on top of Bloc.
>> 
>> You can get it by loading:
>> 
>> Iceberg enableMetacelloIntegration: true.
>> Metacello new
>>baseline: 'GToolkit';
>>repository: 'github://feenkcom/gtoolkit/src';
>>load.
>> 
>> For example, you can then inspect:
>> 'PATH_TO_ICEBERG/feenkcom/gtoolkit/doc/transcript/index.pillar’ 
>> asFileReference
>> 
>> Cheers,
>> Doru
>> 
>> 
>> 
>>> On Nov 10, 2017, at 12:58 PM, H. Hirzel 
>>>  wrote:
>>> 
>>> A note:
>>> 
>>> Tudor Girba wrote:
>>> 
>>> 
>>> Fri, Aug 25, 2017 at 1:31 PM
>>> Reply-To: Any question about pharo is welcome 
>>> 
>>> 
>>> To: Any question about pharo is welcome 
>>> 
>>> 
>>> 
>>> Hi,
>>> 
>>> As mentioned in an announcement about 10 days ago, we are building a
>>> Pillar editor with inline viewing abilities in Bloc. Here is how it
>>> looked like. Please note the embedded picture. We continued working on
>>> it since then and we will probably announce the next version this
>>> weekend:
>>> 
>>> 
>>> Maybe there is now enough progress to do simple presentations in Bloc?
>>> 
>>> 
>>> On 11/10/17, H. Hirzel 
>>> 
>>>  wrote:
>>> 
>>>> Hello
>>>> 
>>>> In the thread 'including Pillar in Pharo image by default' it was
>>>> suggested by Stephane Ducasse to include a subset of Pillar in the
>>>> Pharo image[1] .
>>>> 
>>>> I'd like to extend that proposal a little bit it in order  to do very
>>>> simple presentations. This should allow to describe at least part of
>>>> the slides used in the MOOC course [3].
>>>> 
>>>> This will be  _a possible_ solution to the question  brought up in the
>>>> thread 'Writing "powerpoint" like presentations in Pharo?'.
>>>> 
>>>> Another use is to write instructions with executable content within
>>>> the image ("Assistants").
>>>> 
>>>> So below is the a proposal for a Pillar syntax _subset_ for class
>>>> comments and _simple_ presentations.
>>>> The numbering scheme follows the 'Pillar syntax cheat sheet' [2]
>>>> 
>>>> 
>>>> 
>>>> 
>>>> MINI PILLAR SYNTAX (a subset of Pillar)
>>>> 
>>>> 1. Headers
>>>> 
>>>>!Header 1
>>>>!!Header 2
>>>>!!!Header 3
>>>> 
>>>> 
>>>> 2. Lists
>>>> 
>>>>- Unordered List
>>>># Ordered list
>>>> 
>>>> 
>>>> 
>>>> 5. Emphasis
>>>> 
>>>>""bold""
>>>> 
>>>> 
>>>> 6. Code blocks
>>>> 
>>>> [[[
>>>> Transcript show: 'Hello World'.
>>>> \]]]
>>>> 
>>>> 
>>>> 9. Annotation
>>>> 
>>>> ${slide:title=About Pharo}$
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Next week I plan to implement the rendering of this 'Mini Pillar' in
>>>> Morphic using the Morphic API subset that works in Pharo and Squeak.
>>>> 
>>>> A renderer using Bloc would also be nice. [4]
>>>> 
>>>> Comments, suggestions, code snippets and other help is welcome.
>>>> 
>>>> Regards
>>>> Hannes
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ---

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

[Tudor Girba]

What operating system are you on? What version of Pharo do you use? Is it 32b 
or 64b?

Cheers,
Doru


> On Nov 14, 2017, at 5:33 PM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> 
> 
> On 14/11/17 10:36, Offray Vladimir Luna Cárdenas wrote:
> 
> [...]
>> I have thought that Git is overcomplicated for most of the developers'
>> tasks and communities. I don't know if the root of previous issues is
>> in the "Iceberg enableMetacelloIntegration: true" line, but having to
>> get your pair of keys working to just install software is overkill for
>> the common user (and when LibGit errors are present, the documented
>> solutions don't work seamlessly). Maybe a more sensitive solution
>> would be just to use libgit, without any ssh auth to clone
>> repositories and its prerequisites or even better, some download that
>> goes to the files in the tip (or other) version without all this
>> overhead. 
> 
> In fact, using "Iceberg enableMetacelloIntegration: false" produce a
> smoother installing experience. Putting this as the first line of the
> script doesn't help to most of the users if we want to enable easy
> feedback. Anyway, after a mostly successful installation, Moz2D
> installation failed, downloading a ~20Mb file and after that saying:
> "Moz2D library is not installed correctly. Select Proceed to continue,
> or close this window to cancel the operation." That made most of the
> examples non functional because of the lack of Moz2D or because some
> deprecation.
> 
> Any other way to install Moz2D on Manjaro/Arch Linux or to disable it an
> still be able to use Pillar preview features?
> 
> Cheers,
> 
> Offray
> 
> 

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

"When people care, great things can happen."

Re: [Pharo-users] About suggestions on Pillar editor (was Re: [ann] pillar text editor)

[Tudor Girba]

Hi,

Please retry again by loading the #development version in Pharo 6.1:

Gofer new 
smalltalkhubUser: 'Pier' project: 'Pillar';
configuration;
loadDevelopment.

You should get the extension out of the box.

Please let me know if it works.

Cheers,
Doru


> On Nov 14, 2017, at 5:55 PM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> Hi,
> 
> A suggestion from one year ago. Should be this converted into issues?
> 
> Cheers,
> 
> Offray
> 
> On 10/10/16 13:26, Offray Vladimir Luna Cárdenas wrote:
>> Hi Doru,
>> 
>> I was exploring Stephan Eggermont's code Panel because the zooming in/out 
>> behavior implemented there, but I would like to add your Pillar text editor 
>> to the exploration. 
>> I would like to add two things:
>> 
>> 1. Font decrease/increase buttons/shorcuts, because for long documents, 
>> default font size can be tiresome.
>> 
>> 2. Augmenting the amount of syntax highlighting languages, starting with 
>> markdown. I think that this would be strategic in making writing inside the 
>> image, more appealing, giving the spread of markdown as a documentation 
>> syntax in different context (GitHub, Scholar markdown, wikis, discussion, 
>> Slack clones, etc).
>> I installed the extension today on a Pharo 5 system, but trying to use it, 
>> bring me the error detailed at the end of this mail, so after having it 
>> working on Pharo, I would like to explore/help in implementing items 1 and 
>> 2, avove.
>> 
>> Cheers,
>> 
>> Offray
>> 
>> Error report
>> ===
>> Author: OffrayLuna
>> 
>> Array(Object)>>shouldNotImplement
>> Array(ArrayedCollection)>>add:
>> [ :each | self add: each ] in Array(Collection)>>addAll:
>> Array(SequenceableCollection)>>do:
>> Array(Collection)>>addAll:
>> [ :array | 
>> ({array first}
>> addAll: array last;
>> yourself)
>> collect: [ :each | 
>> ('' join: each first)
>> -> (each second ifNotNil: [ :second | '' join: second ]) ] ] in 
>> GTPillarHighlighter>>scriptParameters
>> PPActionParser>>parseOn:
>> PPDelegateParser>>parseOn:
>> PPSequenceParser>>parseOn:
>> PPActionParser>>parseOn:
>> PPDelegateParser>>parseOn:
>> PPChoiceParser>>parseOn:
>> PPDelegateParser>>parseOn:
>> PPChoiceParser>>parseOn:
>> PPPossessiveRepeatingParser>>parseOn:
>> PPDelegateParser>>parseOn:
>> PPEndOfInputParser>>parseOn:
>> GTPillarHighlighter(PPDelegateParser)>>parseOn:
>> GTPillarHighlighter(PPParser)>>parseWithContext:
>> GTPillarHighlighter(PPParser)>>parse:withContext:
>> GTPillarHighlighter(PPParser)>>parse:
>> GTPillarHighlighterTextDecorator>>parse:onError:
>> GLMHighlighterTextParserStyler>>privateStyle:
>> [ self privateStyle: text.
>> view ifNotNil: [ view stylerStyledInBackground: text ] ] in [ 
>> backgroundProcess := [ self privateStyle: text.
>> view ifNotNil: [ view stylerStyledInBackground: text ] ]
>> forkAt: Processor userBackgroundPriority ] in 
>> GLMHighlighterTextParserStyler(SHTextStyler)>>styleInBackgroundProcess:
>> [ self value.
>> Processor terminateActive ] in BlockClosure>>newProcess
>> ===
>> 
>> On 09/10/16 16:23, Tudor Girba wrote:
>>> Hi,
>>> 
>>> Pillar now ships with a text editor that also features a syntax highlighter.
>>> 
>>> So, now, if you load the development version of Pillar:
>>> 
>>> Gofer new 
>>> smalltalkhubUser: 'Pier' project: 'Pillar';
>>> configuration;
>>> loadDevelopment.
>>> 
>>> You will have an extra presentation when inspecting a .pillar file:
>>> 
>>> 
>>> 
>>> The new thing here is that the highlighter is based on the Pillar 
>>> PetitParser, and it is extensible for highlighting more parts if needed. 
>>> The highlighting also can support actions. For example, the picture above 
>>> shows the file to the right after clicking on the reference.
>>> 
>>> Please take a look and let me know what you think.
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> 
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>> 
>>> "Things happen when they happen,
>>> not when you talk about them happening."
>>> 
>> 
> 

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

"We are all great at making mistakes."

Re: [Pharo-users] About implementing a "Mini Pillar" in-image renderer for Pharo ...

[Tudor Girba]

>>  exists and is not an empty directory. I delete that directory and try an 
>> installation... again
>>  • Now I get: "Instance of FileReference did not understand #notEmpty". 
>> I try to make sense of it in the debugger. My user is git, my public and 
>> private ssh keys are not empty. Despite of not making sense of all I 
>> understand that is trying to clone something at 
>> g...@github.com:feenkcom/gtoolkit.git. I go to my image dir and then to 
>> `iceberg/feenkcom/gtoolkit/`. There is a git repository there, but is empty.
>>  • Now I wonder, maybe if I can just clone the directory there, but how 
>> I say Iceberg to load it? So I run now only the Metacello part. Same error 
>> and solution that the last time but now for gtoolkit-visualizer, Brick, 
>> gtoolkit-examples, Bloc and Sparta.
>>  • After getting my ssh keys, overcome config problems in shell and the 
>> Pharo settings, chasing these errors and solving them by cloning the 
>> repositories manually, I'm, a couple of hours later, ready to test GT 
>> Documenter, but with the last Iceberg's duplicated repository message about 
>> Sparta I give up. Is not nice to start your day accumulating frustration... 
>> that sets a bad mood for the rest of it, and you need to actively fight 
>> against.
>> I have thought that Git is overcomplicated for most of the developers' tasks 
>> and communities. I don't know if the root of previous issues is in the 
>> "Iceberg enableMetacelloIntegration: true" line, but having to get your pair 
>> of keys working to just install software is overkill for the common user 
>> (and when LibGit errors are present, the documented solutions don't work 
>> seamlessly). Maybe a more sensitive solution would be just to use libgit, 
>> without any ssh auth to clone repositories and its prerequisites or even 
>> better, some download that goes to the files in the tip (or other) version 
>> without all this overhead.
>> 
>> Anyway, as I said, I have been unable to test GT Documenter properly and 
>> getting feedback over GT Tools from the team usually requires a lot of 
>> effort in my case (insisting on getting answers or getting none). And that 
>> is just to test a promising tech that still doesn't offer saving features 
>> (just and awesome preview). I think that a more sensible approach for a good 
>> documentation toolkit for now is on Spec and creating custom syntax 
>> highlighters with SmaCC[3], that is well documented and works today.
>> [3] 
>> https://medium.com/@juliendelplanque/hacking-a-simple-syntactic-highlighter-around-specs-textmodel-44ba2e2b1ab9
>> I understand that community is trying its best, but expressing how current 
>> offerings are not mature and constructive criticism can help on that. At the 
>> moment my feeling is that if you want to try the new shinny alpha stuff from 
>> GT Documenter, you will need to be prepared for a lot of frustration and 
>> silence.
>> 
>> Cheers,
>> 
>> Offray
>> 
>> 
>> On 10/11/17 12:41, Tudor Girba wrote:
>>> Hi,
>>> 
>>> As shown at ESUG, GT Documenter offers an advanced viewer (and editor) for 
>>> Pillar working on top of Bloc.
>>> 
>>> You can get it by loading:
>>> 
>>> Iceberg enableMetacelloIntegration: true.
>>> Metacello new
>>>baseline: 'GToolkit';
>>>repository: 'github://feenkcom/gtoolkit/src';
>>>load.
>>> 
>>> For example, you can then inspect:
>>> 'PATH_TO_ICEBERG/feenkcom/gtoolkit/doc/transcript/index.pillar’ 
>>> asFileReference
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> 
>>> 
>>>> On Nov 10, 2017, at 12:58 PM, H. Hirzel 
>>>>  wrote:
>>>> 
>>>> A note:
>>>> 
>>>> Tudor Girba wrote:
>>>> 
>>>> 
>>>>Fri, Aug 25, 2017 at 1:31 PM
>>>> Reply-To: Any question about pharo is welcome 
>>>> 
>>>> 
>>>> To: Any question about pharo is welcome 
>>>> 
>>>> 
>>>> 
>>>> Hi,
>>>> 
>>>> As mentioned in an announcement about 10 days ago, we are building a
>>>> Pillar editor with inline viewing abilities in Bloc. Here is how it
>>>> looked like. Please note the embedded picture. We continued working on
>>>> it since then and we will probably announce the next version this
>>>> weekend:
>>>> 
>>&g

Re: [Pharo-users] About suggestions on Pillar editor (was Re: [ann] pillar text editor)

[Tudor Girba]

There are two presentations (tabs):
- ‘Contents' shows the plain file
- ‘Pillar’ shows the syntax highlighting.

Can you check?

Doru


> On Nov 14, 2017, at 9:57 PM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> Thanks Doru,
> 
> Installation works, but syntax hightligthning and image preview are
> disabled. I don't know if this is because is the same image with the
> installation of GT Documenter, installed.
> 
> Cheers,
> 
> Offray
> 
> 
> On 14/11/17 12:15, Tudor Girba wrote:
>> Hi,
>> 
>> Please retry again by loading the #development version in Pharo 6.1:
>> 
>> Gofer new 
>>smalltalkhubUser: 'Pier' project: 'Pillar';
>>configuration;
>>loadDevelopment.
>> 
>> You should get the extension out of the box.
>> 
>> Please let me know if it works.
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Nov 14, 2017, at 5:55 PM, Offray Vladimir Luna Cárdenas 
>>>  wrote:
>>> 
>>> Hi,
>>> 
>>> A suggestion from one year ago. Should be this converted into issues?
>>> 
>>> Cheers,
>>> 
>>> Offray
>>> 
>>> On 10/10/16 13:26, Offray Vladimir Luna Cárdenas wrote:
>>>> Hi Doru,
>>>> 
>>>> I was exploring Stephan Eggermont's code Panel because the zooming in/out 
>>>> behavior implemented there, but I would like to add your Pillar text 
>>>> editor to the exploration. 
>>>> I would like to add two things:
>>>> 
>>>> 1. Font decrease/increase buttons/shorcuts, because for long documents, 
>>>> default font size can be tiresome.
>>>> 
>>>> 2. Augmenting the amount of syntax highlighting languages, starting with 
>>>> markdown. I think that this would be strategic in making writing inside 
>>>> the image, more appealing, giving the spread of markdown as a 
>>>> documentation syntax in different context (GitHub, Scholar markdown, 
>>>> wikis, discussion, Slack clones, etc).
>>>> I installed the extension today on a Pharo 5 system, but trying to use it, 
>>>> bring me the error detailed at the end of this mail, so after having it 
>>>> working on Pharo, I would like to explore/help in implementing items 1 and 
>>>> 2, avove.
>>>> 
>>>> Cheers,
>>>> 
>>>> Offray
>>>> 
>>>> Error report
>>>> ===
>>>> Author: OffrayLuna
>>>> 
>>>> Array(Object)>>shouldNotImplement
>>>> Array(ArrayedCollection)>>add:
>>>> [ :each | self add: each ] in Array(Collection)>>addAll:
>>>> Array(SequenceableCollection)>>do:
>>>> Array(Collection)>>addAll:
>>>> [ :array | 
>>>> ({array first}
>>>>addAll: array last;
>>>>yourself)
>>>>collect: [ :each | 
>>>>('' join: each first)
>>>>-> (each second ifNotNil: [ :second | '' join: second ]) ] ] in 
>>>> GTPillarHighlighter>>scriptParameters
>>>> PPActionParser>>parseOn:
>>>> PPDelegateParser>>parseOn:
>>>> PPSequenceParser>>parseOn:
>>>> PPActionParser>>parseOn:
>>>> PPDelegateParser>>parseOn:
>>>> PPChoiceParser>>parseOn:
>>>> PPDelegateParser>>parseOn:
>>>> PPChoiceParser>>parseOn:
>>>> PPPossessiveRepeatingParser>>parseOn:
>>>> PPDelegateParser>>parseOn:
>>>> PPEndOfInputParser>>parseOn:
>>>> GTPillarHighlighter(PPDelegateParser)>>parseOn:
>>>> GTPillarHighlighter(PPParser)>>parseWithContext:
>>>> GTPillarHighlighter(PPParser)>>parse:withContext:
>>>> GTPillarHighlighter(PPParser)>>parse:
>>>> GTPillarHighlighterTextDecorator>>parse:onError:
>>>> GLMHighlighterTextParserStyler>>privateStyle:
>>>> [ self privateStyle: text.
>>>> view ifNotNil: [ view stylerStyledInBackground: text ] ] in [ 
>>>> backgroundProcess := [ self privateStyle: text.
>>>> view ifNotNil: [ view stylerStyledInBackground: text ] ]
>>>>forkAt: Processor userBackgroundPriority ] in 
>>>> GLMHighlighterTextParserStyler(SHTextStyler)>>styleInBackgroundProcess:
>>>> [ self value.
>>>> Processor terminateActive ] in BlockClosure>>newProcess
>>>> ==

[Pharo-users] Bloc installation on Linux [WAS: Re: About implementing a "Mini Pillar" in-image renderer for Pharo ...]

[Tudor Girba]

Hi Offray,

Alex took a look at your specific distro and he found and fixed your issue.

Please try again installing GT/Bloc from scratch in a fresh Pharo 6.1 image.

Please also note that the rendering on Linux is not using Moz2D so it will not 
be as beautiful as in pictures. The reason for this is that there are external 
dependencies that are required and we would need help to figure that setup.

Cheers,
Doru


> On Nov 14, 2017, at 10:07 PM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> Hi,
> 
> The readme is clearer now about Iceberg integration as an option not as
> prerequisite. Installation works, but Pillar preview tab is grey and
> clicking on it rises: "Instance of FFIExternalResourceManager class did
> not understand #removeResource:". Also the syntax highlighting in the
> (plain) Pillar tab is not working and neither the image preview. A plain
> installation of just Pillar (without GT Documenter) got those two
> working once.
> 
> Cheers,
> 
> Offray 
> 
> 
> On 14/11/17 12:37, Tudor Girba wrote:
>> Hi,
>> 
>> We changed the baseline to not require Moz2D on Linux. Could you please try 
>> again?
>> 
>> I also updated the README.
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Nov 14, 2017, at 6:25 PM, Offray Vladimir Luna Cárdenas 
>>>  wrote:
>>> 
>>> Alex,
>>> I understand that frustration on installation could be motivated by other 
>>> issues instead of GT Documenter, but if the team ask to use "Iceberg 
>>> enableMetacelloIntegration: true." in the project readme, where it also 
>>> says that is supported for Pharo 6.1 and 7.0, is natural to think that 
>>> something is wrong with documentation and/or in the project's expectations 
>>> about its intended users and their will to invest the effort, time and 
>>> motivation for "living in the edge". I understand that if we want stuff to 
>>> be improved it should be tested, but also that not all the people that is 
>>> willing to test stuff for Pharo 6.1 needs to live in such edge. Or the 
>>> project is sending a message that is not giving the bests firsts 
>>> impressions, or is going to users which are not intended . I would go for a 
>>> smooth install first and then for collaboration with git. I'll make a pull 
>>> request with the proposal for a better documentation, but my understanding 
>>> about how you can go from the first (user of GT Documenter) to the second 
>>> (developer using Git integration) is not clear.
>>> 
>>> GT Tools has been pretty empowering. I have told that several times and I 
>>> don't think that I have wrote a single line of code in their repos. But is 
>>> getting more difficult just to test and use them and I think that is 
>>> related with the idea that my user *needs* to be also my co-developer, 
>>> starting with their ssh git key pair. If we don't make easier to contribute 
>>> by just making easier to install, there will be no evolution either.
>>> 
>>> Cheers,
>>> 
>>> Offray
>>> 
>>> On 14/11/17 11:45, Aliaksei Syrel wrote:
>>>> Hi Offray,
>>>> 
>>>> I understand your frustration, but with all respect, the fact that you 
>>>> have problems with Iceberg does not mean that GT Documenter or any other 
>>>> GT tool is responsible for described problems.
>>>> 
>>>> Most complains about bloc, brick, whatever is because of unrelated stuff. 
>>>> It is a little bit disappointing. Especially for me, as one of the 
>>>> maintainers. But it is ok, I got used to it :)
>>>> 
>>>> I don’t remember when last time I used stable Pharo (not because it does 
>>>> not exist), simply live on the edge since Pharo4. If no one will use Git 
>>>> and report problems Iceberg will never progress. If no one will use Bloc 
>>>> it will never get “there”. Unfortunately, living on the edge is dangerous, 
>>>> requires effort, motivation and time.
>>>> 
>>>> The script that Doru provided works flawlessly on OSX, we load it almost 
>>>> everyday. !! Bloc is tested on CI and builds are green on Windows, Linux 
>>>> and OSX !!. If computer (CI) manages to install it, I am pretty sure human 
>>>> can do it too. Looks like there is something missing in your 
>>>> configuration, something tiny :) Error handling in Iceberg can be 
>>>> definitely improved, but it is a different story.
>>>> 
>>>> P.S. Documenter

Re: [Pharo-users] Bloc installation on Linux [WAS: Re: About implementing a "Mini Pillar" in-image renderer for Pharo ...]

[Tudor Girba]

Hi Offray,

Please do not forget to try and let us know if it works now.

Cheers,
Doru



> On Nov 15, 2017, at 9:20 AM, Tudor Girba  wrote:
> 
> Hi Offray,
> 
> Alex took a look at your specific distro and he found and fixed your issue.
> 
> Please try again installing GT/Bloc from scratch in a fresh Pharo 6.1 image.
> 
> Please also note that the rendering on Linux is not using Moz2D so it will 
> not be as beautiful as in pictures. The reason for this is that there are 
> external dependencies that are required and we would need help to figure that 
> setup.
> 
> Cheers,
> Doru
> 
> 
>> On Nov 14, 2017, at 10:07 PM, Offray Vladimir Luna Cárdenas 
>>  wrote:
>> 
>> Hi,
>> 
>> The readme is clearer now about Iceberg integration as an option not as
>> prerequisite. Installation works, but Pillar preview tab is grey and
>> clicking on it rises: "Instance of FFIExternalResourceManager class did
>> not understand #removeResource:". Also the syntax highlighting in the
>> (plain) Pillar tab is not working and neither the image preview. A plain
>> installation of just Pillar (without GT Documenter) got those two
>> working once.
>> 
>> Cheers,
>> 
>> Offray 
>> 
>> 
>> On 14/11/17 12:37, Tudor Girba wrote:
>>> Hi,
>>> 
>>> We changed the baseline to not require Moz2D on Linux. Could you please try 
>>> again?
>>> 
>>> I also updated the README.
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> 
>>>> On Nov 14, 2017, at 6:25 PM, Offray Vladimir Luna Cárdenas 
>>>>  wrote:
>>>> 
>>>> Alex,
>>>> I understand that frustration on installation could be motivated by other 
>>>> issues instead of GT Documenter, but if the team ask to use "Iceberg 
>>>> enableMetacelloIntegration: true." in the project readme, where it also 
>>>> says that is supported for Pharo 6.1 and 7.0, is natural to think that 
>>>> something is wrong with documentation and/or in the project's expectations 
>>>> about its intended users and their will to invest the effort, time and 
>>>> motivation for "living in the edge". I understand that if we want stuff to 
>>>> be improved it should be tested, but also that not all the people that is 
>>>> willing to test stuff for Pharo 6.1 needs to live in such edge. Or the 
>>>> project is sending a message that is not giving the bests firsts 
>>>> impressions, or is going to users which are not intended . I would go for 
>>>> a smooth install first and then for collaboration with git. I'll make a 
>>>> pull request with the proposal for a better documentation, but my 
>>>> understanding about how you can go from the first (user of GT Documenter) 
>>>> to the second (developer using Git integration) is not clear.
>>>> 
>>>> GT Tools has been pretty empowering. I have told that several times and I 
>>>> don't think that I have wrote a single line of code in their repos. But is 
>>>> getting more difficult just to test and use them and I think that is 
>>>> related with the idea that my user *needs* to be also my co-developer, 
>>>> starting with their ssh git key pair. If we don't make easier to 
>>>> contribute by just making easier to install, there will be no evolution 
>>>> either.
>>>> 
>>>> Cheers,
>>>> 
>>>> Offray
>>>> 
>>>> On 14/11/17 11:45, Aliaksei Syrel wrote:
>>>>> Hi Offray,
>>>>> 
>>>>> I understand your frustration, but with all respect, the fact that you 
>>>>> have problems with Iceberg does not mean that GT Documenter or any other 
>>>>> GT tool is responsible for described problems.
>>>>> 
>>>>> Most complains about bloc, brick, whatever is because of unrelated stuff. 
>>>>> It is a little bit disappointing. Especially for me, as one of the 
>>>>> maintainers. But it is ok, I got used to it :)
>>>>> 
>>>>> I don’t remember when last time I used stable Pharo (not because it does 
>>>>> not exist), simply live on the edge since Pharo4. If no one will use Git 
>>>>> and report problems Iceberg will never progress. If no one will use Bloc 
>>>>> it will never get “there”. Unfortunately, living on the edge is 
>>>>> dangerous, requires effort, motivation and time.
>>>&

Re: [Pharo-users] Bloc installation on Linux [WAS: Re: About implementing a "Mini Pillar" in-image renderer for Pharo ...]

[Tudor Girba]

Hi,

Thanks for trying the Linux installation.

Let me address the non-installation questions below.



> On Nov 21, 2017, at 12:56 AM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> Hi Doru & Alex,
> 
> Installation works now. During installation process I get this message:
> 
> ===
> 
> This package depends on the following classes:
>   BrTextEditorPieceElement
> You must resolve these dependencies before you will be able to load
> these definitions:
>   BrTextEditorPieceElement>>#drawOnSpartaCanvas:
> 
> ===
> 
> That I imagine, is related with the absence of Moz2D. Also, Pillar
> syntax works now as shown in the first screenshot, but the bloc preview
> looks strange, without preserving proper spacing between characters and
> using crossed boxes for character returns (I imagine that is related
> with Moz2D, but cairo is working, as you can see in the code previews).
> 
> So, some old questions for my response to the feedback request a year
> ago remain and new questions arise.
> 
> The old ones:
> 
> - How can font size of the pillar preview can be increased/decreased on
> demand? Having proper text size for reading and writing text is
> important in a text editor.

The font used is the default text size. To make it customizable, we would need 
to extend the parser and the UI. I do not plan/have time to make these changes 
any time soon, but you are welcome to look at the code and propose changes, or 
simply create your own version.


> - How Pillar markup can be extended/changed to support Markdown?

You cannot extend it. You would need to hook a Markdown parser into the syntax 
highlighter for that.

> The new ones:
> 
> - Which are the requisites for Moz2D on a Linux environment. It can be
> on Ubuntu/Debian. I can try to translate them to Manjaro/Arch.
> 
> - How add line numbers to the "Pillar" tab (similarly to "Contents" tab
> and how to make it the default tab view.

Let’s take a moment to learn how to learn from the existing system once an 
example is available.

An inspector tab is defined in an extension method in the class of the object 
you are inspecting. Look at the Meta tab of a FileReference instance, and you 
get to:

gtInspectorContentsIn: composite

composite text
title: 'Contents';
display: [ 
self readStreamDo: [ :stream | 
| result |
result := [(stream next: 1) 
asString]
on: Error 
do: [ (stream binary next: 
1) asString ].
stream size > 1
ifTrue: [ result, '  ... 
truncated ...' ]
ifFalse: [ result ] ] ];
withLineNumbers: true;


> - How to make the Pillar tab to autosave any changes, in a similar way
> to a spec text widget.

You would have to hook to the change of the #text port in order to add the 
autosave. For an example of how to hook to the #text port changes, take a look 
at GLMBasicExamples>>#onChangeOfPortAction 

Cheers,
Doru



> Cheers,
> 
> Offray
> 
> 
> 
> On 16/11/17 16:32, Tudor Girba wrote:
>> Hi Offray,
>> 
>> Please do not forget to try and let us know if it works now.
>> 
>> Cheers,
>> Doru
>> 
>> 
>> 
>>> On Nov 15, 2017, at 9:20 AM, Tudor Girba  wrote:
>>> 
>>> Hi Offray,
>>> 
>>> Alex took a look at your specific distro and he found and fixed your issue.
>>> 
>>> Please try again installing GT/Bloc from scratch in a fresh Pharo 6.1 image.
>>> 
>>> Please also note that the rendering on Linux is not using Moz2D so it will 
>>> not be as beautiful as in pictures. The reason for this is that there are 
>>> external dependencies that are required and we would need help to figure 
>>> that setup.
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> 
>>>> On Nov 14, 2017, at 10:07 PM, Offray Vladimir Luna Cárdenas 
>>>>  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> The readme is clearer now about Iceberg integration as an option not as
>>>> prerequisite. Installation works, but Pillar preview tab is grey and
>>>> clicking on it rises: "Instance of FFIExternalResourceManager class did
>>>> not understand #removeResource:". Also the syntax highlighting in the
>>>> (plain) Pillar tab is not working and neither the image preview. A plain
>>>> installation of just Pillar (without GT Documenter) got those two
>>>> working once.
>>>> 
>>>> Cheers,
>>>> 
>>>> Offray 
>>>> 
>>>> 
>>>> On 14/11/17 12:37, Tudor Girba wrote:
>>>>> Hi,
>>>>> 
>>>>> We changed the baseline to not require Moz2D on Linux. Could you please 
>>>>> try again?
>>>>> 
>>>>> I also updated the README.
>>>>> 
>>>>> Cheers,
>>>>> Doru
>>>>> 
> 
> 
> 

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

"No matter how many recipes we know, we still value a chef."

Re: [Pharo-users] PetitCompiler loading problem

[Tudor Girba]

Hi,

PetitCompiler is not released for 6.1. Please try with #development and let me 
know if you still encounter the issue.

Cheers,
Doru


> On Nov 24, 2017, at 8:55 AM, Julien  wrote:
> 
> Hello,
> 
> I’d like to try PetitCompiler to speed-up a parser I did.
> 
> When trying to load it in a Pharo 6.1 image I have an error related to its 
> configuration:
> 
> Gofer new smalltalkhubUser: 'JanKurs' project: 'PetitParser';
>configurationOf: #PetitCompiler; load.
> (Smalltalk at: #ConfigurationOfPetitCompiler) perform: #'loadStable'.
> 
> « Error : Name not found : Magritte-Tests-Pharo-Model » 
> 
> Can someone help me?
> 
> I haven't tried in older images.
> 
> Julien

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

"No matter how many recipes we know, we still value a chef."

Re: [Pharo-users] PetitCompiler loading problem

[Tudor Girba]

Hi,

What script are you using?

Cheers,
Doru


> On Nov 24, 2017, at 9:42 AM, Julien  wrote:
> 
> Hi,
> 
> Thanks for you answer.
> 
> I already tried and I do encounter the same issue with #development version.
> 
> Julien
>> Le 24 nov. 2017 à 09:40, Tudor Girba  a écrit :
>> 
>> Hi,
>> 
>> PetitCompiler is not released for 6.1. Please try with #development and let 
>> me know if you still encounter the issue.
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Nov 24, 2017, at 8:55 AM, Julien  wrote:
>>> 
>>> Hello,
>>> 
>>> I’d like to try PetitCompiler to speed-up a parser I did.
>>> 
>>> When trying to load it in a Pharo 6.1 image I have an error related to its 
>>> configuration:
>>> 
>>> Gofer new smalltalkhubUser: 'JanKurs' project: 'PetitParser';
>>>  configurationOf: #PetitCompiler; load.
>>> (Smalltalk at: #ConfigurationOfPetitCompiler) perform: #'loadStable'.
>>> 
>>> « Error : Name not found : Magritte-Tests-Pharo-Model » 
>>> 
>>> Can someone help me?
>>> 
>>> I haven't tried in older images.
>>> 
>>> Julien
>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "No matter how many recipes we know, we still value a chef."
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 

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

"Don't give to get. Just give."

Re: [Pharo-users] Autoupdate of playground contents up to the last keystroke

[Tudor Girba]

Hi,

You are reading the wrong port.

Try this instead:

playground := GTPlayground new.
playground openOn: GTPlayPage new.
playground 
onChangeOfPort: #text 
act: [ :x | self inform: (x pane port: #text) value ]

Cheers,
Doru



> On Nov 28, 2017, at 12:48 AM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> Hi,
> 
> Grafoscopio uses Doru's suggestion for auto-updating its contents, as 
> published in http://ws.stfx.eu/ETEC2JH7363M, but if you test that code you 
> will see that the contents showed in the inform message are one keystroke 
> behind of the current playground content, as showed below, which creates 
> usability issues (we need to add empty spaces and new lines to get the proper 
> content of the Playground saved).
> 
> 
> 
> There is any way to store/show the actual contents of the playground, instead 
> of one keystroke behind.
> 
> Thanks,
> 
> Offray

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

"We are all great at making mistakes."

Re: [Pharo-users] Unable to update Glamour-Core

[Tudor Girba]

Hi,

I am not sure I understand your report. The Glamour-Core package is part of 
ConfigurationOfGlamourCore, and should not be updated separately.

What script are you using for loading ConfigurationOfGlamourCore?

Cheers,
Doru


> On Nov 29, 2017, at 3:53 AM, Offray Vladimir Luna Cárdenas 
>  wrote:
> 
> Hi,
> 
> My image become unresponsive while making some debug, so I decided to
> start fresh and reinstall Grafoscopio, but I have some problems, with
> XML parser (so I disabled Soup temporarily) and with Glamour-Core, which
> provides and important part of the Grafoscopio experience. I tried also
> to install it from Monticello, without better results (to the version
> Glamour-Core-TudorGirba339). In both cases I get "SubscriptOutOfBounds:
> 17808" and this is the trace I get with the "Report" button (sorry I
> don't know other way to report):
> 
> https://pastebin.com/wWM24w01
> 
> I will try with Pharo 7... The procedure is the same that was working
> just last week. I know the pains and advantages of having a dynamic
> system that is evolving quickly... hopefully a more stable platform will
> be there while the upcoming one is evolving.
> 
> Cheers,
> 
> Offray
> 
> 
> 

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

"Every now and then stop and ask yourself if the war you're fighting is the 
right one."

[Pharo-users] feenk log

[Tudor Girba]

Hi,

Here is an update of the work on Bloc and GT:

Bloc:
- Bezier curves (cubic and quadratic).
https://twitter.com/feenkcom/status/93476564021504
https://twitter.com/feenkcom/status/934856909001252865

- Dragging is now possible through a BlDragHandler that can be attached to any 
element.

- Pixel accurate line heads and tails
https://twitter.com/feenkcom/status/936704646290305025

- More flexible scalable element.
https://twitter.com/feenkcom/status/934003681539907585

- Improved scalability of the rendering. For example, on Mac, we are on par 
with the speed of Firefox.
https://twitter.com/feenkcom/status/931462535861108736

- Sparta is now able to load custom fonts.
https://twitter.com/feenkcom/status/930919637214285824

- Text insertion works now much better. Deletion and Selection still require 
more work.

- The rope data structure can now be better inspected.
https://twitter.com/feenkcom/status/937298739584172032

- Sparta/Moz2D has a visual loader that also provides more specific details in 
case of errors.
https://twitter.com/feenkcom/status/936501909581688832

- Moz2D is now installed by default on Linux 64b.


GT:

- The GT Visualizer sub-project now contains two tools:

-- GT Mondrian is a graph visualization engine that is both performant and 
shows how Bloc works well for visualizations. More details in a follow up post.
https://twitter.com/feenkcom/status/937682660704563202

-- GT Connector is a new tool for browsing connected examples. More details 
about it in a follow up post.
https://twitter.com/feenkcom/status/936109463462965248


Enjoy,
The feenk team

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

"If you can't say why something is relevant, 
it probably isn't."

[Pharo-users] [ann] gtmondrian

[Tudor Girba]

Hi,

We are happy to announce GT Mondrian, a graph visualization engine built on top 
of Bloc.

It is similar to the original Mondrian and the Mondrian from Roassal, but it is 
different in that it is built directly out of Bloc elements. This is 
interesting because it allows us to combine typical widgets with 
visualizations. The other interesting thing about it is that it validates the 
design of Bloc: right now, the implementation has 509 lines of code (excluding 
graph-specific layouts). The goal is to make visualization a first class 
citizen and an integral part of the IDE.

The key ingredient that made this happen is that Bloc can now treat graph 
layouts, such as tree or force based, behave under the same rules as typical 
widget layouts, such as grid or flow. The challenge comes from the fact that a 
graph layout depends on the notion of edges between elements, and we did not 
want to have elements know about edges in the core of Bloc.

The solution was to split the typical edge implementation in graph 
visualization libraries into two distinct concepts:
• Line is an element that draws the connections.
• Edge defines constraints imposed by connections between elements.
 
Thus, edges form constraints, and constraints are what layouts deal with. That 
is one reason why elements in bloc have the ability of defining layout-specific 
constraints. Using this, we can nicely define edges between elements as a 
plugin to Bloc, but still be able to connect arbitrary elements. What's more, 
it turns out that we need constraints for other layouts as well. For example, 
an element in a grid layout might specify the span.
 
The API of GT Mondrian is similar to the one from Roassal, but there are a few 
differences as well. These are described in the Pillar documentation available 
in the GitHub repo.

The best way to experience GT Mondrian and its documentation is to load the 
GToolkit as described here:
https://github.com/feenkcom/gtoolkit

If you download the GT code through Iceberg, the documentation can be 
experienced live by inspecting:
'./pharo-local/iceberg/feenkcom/gtoolkit-visualizer/doc/mondrian/index.pillar' 
asFileReference
 

 




 
Cheers,
The feenk team


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

"Quality cannot be an afterthought."

Re: [Pharo-users] Simplest 'REPL'

[Tudor Girba]

Hi,

I would encourage you to simply extend the inspector. Something like this:

MyEvaluator>>gtInspectorEvaluateIn: composite

composite text
title: ‘Evaluator’;
populate: #selection iconName:#glamorousGo entitled: ‘Evaluate' 
with: [ :textPresentation | 
self from: (MyReader from: textPresentation text)]

And then inspect MyEvaluator new.

If you cannot have an evaluator instance without the reader, add the extension 
to the class side of MyEvaluator and inspect the MyEvaluator class.

Cheers,
Doru



> On Dec 9, 2017, at 12:04 AM, cheshirecatalyst  wrote:
> 
> I've recently picked up pharo, and am writing a small interpreter for a 
> trivial language the details of which are unimportant. However I am looking 
> for the simplest way to avoid having to use playground and Transcript to do 
> something like
> 
> | reader eval |
> reader := MyReader from: 'some stuff in my DSL'.
> eval := MyEvaluator from: reader.
> Transcript show: eval evaluate.
> 
> I'm tired of having to change 'some stuff in my DSL' to a new expression and 
> run it in playground.
> 
> I don't really care which is easier, a Morphic with an input box at the 
> bottom to put my expressions in with output up top, or a something like 
> CommandShellTranscript (which i have looked at but is too complex for me to 
> figure out how to get the desired result from).
> 
> Basically I want to be able to use my DSL outside of playground, but still in 
> image. 

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

"Yesterday is a fact.
 Tomorrow is a possibility.
 Today is a challenge."

Re: [Pharo-users] Metacello with Git

[Tudor Girba]

Hi,

We also use private GitHub projects with Iceberg and it works fine.

Cheers,
Doru


> On Dec 20, 2017, at 10:50 AM, Norbert Hartl  wrote:
> 
> 
> 
>> Am 20.12.2017 um 04:02 schrieb Sean P. DeNigris :
>> 
>> CyrilFerlicot wrote
>>> For bitbucket you can use bitbucket://.
>>> I don't know for gitlab.
>> 
>> Unless something has changed, the cool git URLs only work for public
>> projects. In any case, it was not possible to authenticate with SSH keys
>> last time I checked (so I could not use them)…
>> 
>> 
> Au contraire! It works really good with SSH keys. I work all day with it. I 
> added support for bitbucket to iceberg because I’m using bitbucket private 
> repos in my company.
> 
> Norbert
> 

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

"We cannot reach the flow of things unless we let go."

Re: [Pharo-users] A playground for Markdown?

[Tudor Girba]

> On Dec 31, 2017, at 4:03 PM, Serge Stinckwich  
> wrote:
> 
> 
> 
> On Sun, Dec 31, 2017 at 4:00 PM, Sean P. DeNigris  
> wrote:
> Offray Vladimir Luna Cárdenas-2 wrote
> > a versatile Playground that supports several syntax
> > highlighting (and some supporting behavior)
> 
> That actually could be amazing because sometimes I'm forced to use other
> syntaxes (especially markups nowadays) and I'd probably be much happier
> editing Markdown in Pharo than in the GH web UI! This actually just reminded
> me of Lukas' Helvetia and Language Boxes. Offray, I have no idea if it's
> relevant or useful (the project was from 2009), but you may want to have a
> look. Here's one link: http://scg.unibe.ch/research/helvetia
> 
> 
>  
> ​We made a new version of Helvetia running on Pharo 5.0:
> https://github.com/UMMISCO/Helvetia

Nice!

Doru

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

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

"Be rather willing to give than demanding to get."

Re: [Pharo-users] Pharo Lecture at Tunis next week

[Tudor Girba]

Thanks a lot for the effort of promoting and spreading Pharo!

Doru


> On Jan 13, 2018, at 1:36 PM, Stephane Ducasse  wrote:
> 
> Hi guys
> 
> just to tell you that next week I will give a lecture at ENIS at tunis.
> 3 full days of Pharo and advanced design.
> 
> Stef
> 

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

"Innovation comes in the least expected form. 
That is, if it is expected, it already happened."

[Pharo-users] bloc next experiments

[Tudor Girba]

Hi,
 
Happy New Year!
 
We were asked about the roadmap of Bloc several times. It is a perfectly 
reasonable request given that Bloc is supposed to offer the UI infrastructure 
for the future of Pharo.

However, I was reluctant to provide one because we do not really have a classic 
roadmap. When we develop Bloc and GT we think in terms of experiments and 
examples that we want to play with to get us to our goal. Features are a 
consequence of that. This approach allowed us on multiple occasions to stumble 
across functional possibilities that we would have not been able to think about 
before seeing the experiments. It also works the other way around: as we move 
ahead, we sometime discover modeling problems and we sometimes chase them all 
the way down.

Having said that, we can specify the next examples and experiments that we 
consider for the next months. Here they are: 
• Drag and drop that can be customized on an instance basis. In the process, 
revisit event management and explore making it use Announcements. Use this for 
the diagramming engine.
• Scrollbar for infinite list and the scalable element.
• Apply layout once. For example, this would allow us to apply a layout but 
still be able to drag elements in custom positions without disturbing the 
others. The first application is in the context of creating diagrams and 
visualizations.
• Apply layout with animation. For example, in Connector, a new example should  
be spawned and moved to its position through a smooth animation. This will also 
allow us to play with the concept of animation and MVVM.
• Introduce the concept of elevation. This is important for scenes in which we 
have overlapping elements that are not part of the composition tree. For 
example, in Connector, the lines connect inner elements inside the text, but 
they belong to the root. such as a visualization (but not only). For this to 
work, we need a better element traversing structure.
• Experiment with theming. The theming mechanism should be instance specific 
with per-widget defaults, and the theme values should ideally be injected in 
the widgets. The CSS implementation from Glenn is one direction. As developing 
and maintaining themes can be a nightmare in the long run, the theming 
mechanism to provide debugging tools.
• Experiment with delegating animations through the model. Typical MVVM or MVC 
focus on the behavior of an interaction. We want to get smooth  live interfaces 
and the animation logic should be influence-able  by the model. For example, 
hovering over a button, enlarges the button with extra details about the action.
• Basic widgets: list, input box, button, radio button, checkbox, menu, 
dropdown menu, toggling button, tabs, toolbar.
• Table and tree widgets.
• Pager interface (similar to the one in the current inspector) with resizable 
panes.

Have fun,
The feenk team

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

"Presenting is storytelling."

Re: [Pharo-users] [ANN] OpenSSL-Pharo works on Windows

[Tudor Girba]

Thanks a lot!

Doru


> On Dec 20, 2017, at 8:55 AM, Pierce Ng  wrote:
> 
> Hi all,
> 
> OpenSSL-Pharo now works on Windows. Tested on Windows 10 with a fresh 32-bit
> Pharo 6.1 zip package downloaded from pharo.org. On Windows this library uses
> libeay.dll which is bundled with the Pharo VM.
> 
>  Metacello new
>baseline: 'OpenSSL';
>smalltalkhubUser: 'PierceNg' project: 'OpenSSL-Pharo';
>load.
> 
> Pierce
> 
> 

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

"No matter how many recipes we know, we still value a chef."

Re: [Pharo-users] unsolicited package-cache use

[Tudor Girba]

Should we not block this account? It looks generated … although it is quite 
scary how not easy it is to not figure this out.

Cheers,
Doru


> On Jan 18, 2018, at 12:04 PM, Kjell Godo  wrote:
> 
> it’s those weight limits on the luggage they spook you
>  they spooked me they spooked us
>  but they are not really limits you just have to pay more
>  but you don’t actually find that out until you get there
>  or if you want to spend an hour on the phone asking about it
>   well probably only 20 minutes actually 
>   but you have to know that you can ask this question
>that it is a valid question to ask
>which apparently we did not
>  so i left something behind Won’t do that again
> 
> On Thu, Jan 18, 2018 at 02:45 Kjell Godo  wrote:
> i want it I’m going to get it if i can click download on it
>  i don’t care about 43MB
> 
> is there an image stripper? ( Dolphin has an image stripper you can modify.
>  after stripping the .exe file was about 6MB )
> 
> if this is 43MB of just DrGeo then i think it’s fine
>  i don’t know what anybody else thinks and i don’t know much but
>  it takes a few minutes to download 
>  at 1.5Mbits / second
>  not really noticeable
>  it has to be above 100MB at that speed to be noticeable
>  in my opinion
> 
> so can i do differential geometry in DrGeo?
>  like general relativity? that would be cool.
>  can it do Tensors? i have this 
>   book : einstein gravity in a nutshell
>   and i have always wanted a numerical graphical way to go through
>   these equations in there
>  i guess there is that numerical package i got, is there a tensor package?
>  i tried to write a tensor thing once
>  i tried to boil it down to the minimum number of lines of 
>   KEGGenerator code and that was like 10 or less
>   to do a tensor multiply
>   but i never tested it yet Test first!
> 
> so i want to get DrGeo now and i don’t care about 43MB
>  now or soon it’s not really possible right now
>  usually it would be but i am out of my usual country
> 
> 
> On Thu, Jan 18, 2018 at 00:33 Hilaire  wrote:
> Le 18/01/2018 à 05:30, Hernán Morales Durand a écrit :
> > Which Pharo version?
> P7
> > Have you found any solution to this?
> 
> I find a workaround.  My bash script to build DrGeo image just remove
> the content of the package-cache directory.
> > In Gofer there was #disablePackageCache, in Metacello I don't know,
> > maybe experimenting with MetacelloLoaderPolicy but there are no class
> > comments.
> 
> I am now done with this problem, and I will not get back to it right now.
> Thanks to ask and the suggestion, it could be useful to other.
> 
> I have other serious concern as the resulting size of the DrGeo image
> built against P7, 43MB. I feel ashame to make any public DrGeo release
> with such an important image size.
> 
> Hilaire
> 
> 
> 
> 
> --
> Dr. Geo
> http://drgeo.eu
> 
> 
> 

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

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

Re: [Pharo-users] Working directory

[Tudor Girba]

+1

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

> On 19 Jan 2018, at 02:11, Ben Coman  wrote:
> 
>> On 18 January 2018 at 14:33, Alistair Grant  wrote:
>> Hi Hernán,
>> 
>> On 18 January 2018 at 05:41, Hernán Morales Durand
>>  wrote:
>>> 
>>> Note that in R you can set the current working directory with setwd()
>>> and this is very common in R scripts.
>>> 
>>> I like the idea around #imageDirectory and #vmStartupDirectory or just
>>> #vmDirectory.
>>> And maybe renaming #workingDirectory to #userWorkingDirectory would be
>>> more clear? Assuming 1 image = 1 user?
>> 
>> In Pharo 7:
>> 
>> FileLocator workingDirectory = C getcwd()  # same as R and most languages
>> FileLocator imageDirectory = the directory where the image is located
>> FileLocator vmDirectory = the directory where the vm is located
> 
> I like the distinction of having all three.
> 
> cheers -ben
> 

Re: [Pharo-users] [ann] pillar support in gtinspector

[Tudor Girba]

Hi,

Thanks for the feedback. Indeed, your points are much inline with where we
should go next.

On Sun, Sep 7, 2014 at 9:50 PM, Offray Vladimir Luna Cárdenas <
off...@riseup.net> wrote:

> Hi Doru,
>
> I really like the advancements in this direction. If fact what I have
> trying to do, as a newbie, by making a Glamorous Toolkit powered
> outliner/tree like interface for writing structured documents tries
> something similar. I think that writing is mainly a non-linear experience
> and the usual metaphors of document processors are not powerful enough in
> expressing/exploring the structure of ideas in the writing process (some
> thought about it ane examples about how implement non-linear academic
> writing are in [1], in Spanish).
>
> [1] http://mutabit.com/offray/static/blog/output/posts/la-
> forma-en-que-escribo-para-el-doctorado.html
>
> I would like to create Visual Data Narratives inside Pharo/Moose/Roassal
> that use file system and web, and LateX as "exportation formats", but where
> the writing/structuring experience happen mainly inside Pharo. For that
> persistence/change of trees is important, but as I have documented in other
> threads, I'm having problems with it, using Glamorous Toolkit (specifically
> on updating objects from text panes and from emergent windows for tree
> names/properties).
>
> With your post, I'm wondering who difficult is:
>
> a. To put support to Pillar/Markdown inside text panes (something similar
> to the "smalltalkCode" message for showing Smalltalk in text panes but with
> "pillarCode" or "markdownCode" (or some dictionary with the #syntax keyword
> and the language as a value).
>

That is precisely what already happened. If you load the code, you can take
a look at the FileReference>>gtInspectorPillarIn: method to see how to
specify the presentation.


> b. To execute some parts of the code, for example the ones that are inside
> "[[[" "]]]" while the cursor is there, so we could not only preview
> imagages, but also execute code for visualizations or other computations
>

Exactly. That should definitely be a direction. We need to experiment here
with the exact semantics. For example, you will not always want to execute
the code. Or not all code is meant to be executed.


> c. The ability to support drag and drop to files to the tree (a Glamorous
> Tree) and get some kind of node pointing to that file.
>

That is indeed something I would want as well. For example, we should be
able to drag and drop a pier file from the outside and spawn an editor on
it.



> d. Tha ability to preview thumbnail images in a similar way of the
> "contextual places" for printing described on your post at [2]
>
> [2] http://www.humane-assessment.com/blog/rethinking-print-it-in-pharo
>

Yes. This will likely come soon :)

e. The hability to show a preview of the pdf/html in an emergent lateral
> panel in a simlar way to what TeXStudio or TeXmaker do[3]
>
> [3] http://www.xm1math.net/texmaker/texmakertop_big.png


I do not know how to do it at this time. For this purpose, we would need to
be able to embed a browser in a Pharo UI, and I am not aware of how to do it


>
> So here I put my other ideas about "bringing liveliness to documentation"
> as you said and I would like to build them together.
>

Great. Please keep experimenting and keep us posted.

Cheers,
Doru



> Cheers,
>
> Offray
>
> Ps: In the other threads I'm asking about how to advance in the outliner
> metaphor for live doc writing on Pharo/Moose/Roassal. I'll keep you posted.
>
> On 09/07/2014 08:41 AM, Tudor Girba wrote:
>
>> Hi,
>>
>> Documentation is important. To make it more likely and more enjoyable for
>> people
>> to write more of it, I teamed up with Andrei and Jan to build up support
>> for
>> Pillar in the GTInspector.
>>
>> The current solution brings the following:
>> - Pillar specific syntax highlighting including Shout highlighting for
>> code snippets
>> - Embedded files validation and preview possibility
>> - Quick browsing of Pillar book projects when inspecting the book folder
>> - Class comment rendering using Pillar syntax when inspecting the class
>> object
>> - Text editor support for custom highlighting in Glamour (using Rubric
>> for now)
>> - Island parsing for quick specification of incomplete parser
>>
>> You can learn more about it here:
>> http://www.humane-assessment.com/blog/writing-pillar-books-
>> with-the-gtinspector
>>
>> Inline image 1
>>
>> There is much more to do in this direction, and I would be happy to
>> inspire some
>> of you to join forces. Please let us know what you think.
>>
>> Cheers,
>> Doru
>>
>> --
>> www.tudorgirba.com <http://www.tudorgirba.com>
>>
>> "Every thing has its own flow"
>>
>>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] [ann] pillar support in gtinspector

[Tudor Girba]

Hi Ben,

Exactly. In Pier, we used to have value links (see
http://www.piercms.com/doc/syntax).

I propose to introduce something like this:

+object:"code that returns something that can be embedded like a graphical
form"+


Doru


On Mon, Sep 8, 2014 at 12:47 AM, Ben Coman  wrote:

> Offray Vladimir Luna Cárdenas wrote:
>
>> Hi Doru,
>>
>> I really like the advancements in this direction. If fact what I have
>> trying to do, as a newbie, by making a Glamorous Toolkit powered
>> outliner/tree like interface for writing structured documents tries
>> something similar. I think that writing is mainly a non-linear experience
>> and the usual metaphors of document processors are not powerful enough in
>> expressing/exploring the structure of ideas in the writing process (some
>> thought about it ane examples about how implement non-linear academic
>> writing are in [1], in Spanish).
>>
>> [1] http://mutabit.com/offray/static/blog/output/posts/la-
>> forma-en-que-escribo-para-el-doctorado.html
>>
>> I would like to create Visual Data Narratives inside Pharo/Moose/Roassal
>> that use file system and web, and LateX as "exportation formats", but where
>> the writing/structuring experience happen mainly inside Pharo. For that
>> persistence/change of trees is important, but as I have documented in other
>> threads, I'm having problems with it, using Glamorous Toolkit (specifically
>> on updating objects from text panes and from emergent windows for tree
>> names/properties).
>>
>> With your post, I'm wondering who difficult is:
>>
>> a. To put support to Pillar/Markdown inside text panes (something similar
>> to the "smalltalkCode" message for showing Smalltalk in text panes but with
>> "pillarCode" or "markdownCode" (or some dictionary with the #syntax keyword
>> and the language as a value).
>>
>> b. To execute some parts of the code, for example the ones that are
>> inside "[[[" "]]]" while the cursor is there, so we could not only preview
>> imagages, but also execute code for visualizations or other computations
>>
>
> I have been thinking previously, that it would be good to have named code
> blocks "[[[ ]]]", some of which are visible which appear in the end
> document, and some are invisible, just used to scaffold the live document,
> e.g. to generate pictures.  For example, visible code block code A might
> show the text to "create a class definition and accessors" and invisible
> code block B might say...
> "close all windows.
> run code block A.
> open System Browser at origin: 100@100 extent 500@300.
> System Browser select class and accessor just created.
> Screen snapshot and save to filenameXXX.png."
>
> cheers -ben
>
>
>
>> c. The ability to support drag and drop to files to the tree (a Glamorous
>> Tree) and get some kind of node pointing to that file.
>>
>> d. Tha ability to preview thumbnail images in a similar way of the
>> "contextual places" for printing described on your post at [2]
>>
>> [2] http://www.humane-assessment.com/blog/rethinking-print-it-in-pharo/
>>
>> e. The hability to show a preview of the pdf/html in an emergent lateral
>> panel in a simlar way to what TeXStudio or TeXmaker do[3]
>>
>> [3] http://www.xm1math.net/texmaker/texmakertop_big.png
>>
>>
>> So here I put my other ideas about "bringing liveliness to documentation"
>> as you said and I would like to build them together.
>>
>> Cheers,
>>
>> Offray
>>
>> Ps: In the other threads I'm asking about how to advance in the outliner
>> metaphor for live doc writing on Pharo/Moose/Roassal. I'll keep you posted.
>>
>> On 09/07/2014 08:41 AM, Tudor Girba wrote:
>>
>>> Hi,
>>>
>>> Documentation is important. To make it more likely and more enjoyable
>>> for people
>>> to write more of it, I teamed up with Andrei and Jan to build up support
>>> for
>>> Pillar in the GTInspector.
>>>
>>> The current solution brings the following:
>>> - Pillar specific syntax highlighting including Shout highlighting for
>>> code snippets
>>> - Embedded files validation and preview possibility
>>> - Quick browsing of Pillar book projects when inspecting the book folder
>>> - Class comment rendering using Pillar syntax when inspecting the class
>>> object
>>> - Text editor support for custom highlighting in Glamour (using Rubric
>>> for now)
>>> - Island parsing for quick specification of incomplete parser
>>>
>>> You can learn more about it here:
>>> http://www.humane-assessment.com/blog/writing-pillar-books-
>>> with-the-gtinspector
>>>
>>> Inline image 1
>>>
>>> There is much more to do in this direction, and I would be happy to
>>> inspire some
>>> of you to join forces. Please let us know what you think.
>>>
>>> Cheers,
>>> Doru
>>>
>>> --
>>> www.tudorgirba.com <http://www.tudorgirba.com>
>>>
>>> "Every thing has its own flow"
>>>
>>>
>>
>>
>>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] [ann] pillar support in gtinspector

[Tudor Girba]

Maybe ... would anyone be interested in giving it a try? :)

Doru


On Mon, Sep 8, 2014 at 12:57 AM, Ben Coman  wrote:

>  Tudor Girba wrote:
>
> Hi,
>
> Thanks for the feedback. Indeed, your points are much inline with where we
> should go next.
>
> On Sun, Sep 7, 2014 at 9:50 PM, Offray Vladimir Luna Cárdenas 
>  wrote:
>
>
>
>  Hi Doru,
>
> I really like the advancements in this direction. If fact what I have
> trying to do, as a newbie, by making a Glamorous Toolkit powered
> outliner/tree like interface for writing structured documents tries
> something similar. I think that writing is mainly a non-linear experience
> and the usual metaphors of document processors are not powerful enough in
> expressing/exploring the structure of ideas in the writing process (some
> thought about it ane examples about how implement non-linear academic
> writing are in [1], in Spanish).
>
> [1] http://mutabit.com/offray/static/blog/output/posts/la-
> forma-en-que-escribo-para-el-doctorado.html
>
> I would like to create Visual Data Narratives inside Pharo/Moose/Roassal
> that use file system and web, and LateX as "exportation formats", but where
> the writing/structuring experience happen mainly inside Pharo. For that
> persistence/change of trees is important, but as I have documented in other
> threads, I'm having problems with it, using Glamorous Toolkit (specifically
> on updating objects from text panes and from emergent windows for tree
> names/properties).
>
> With your post, I'm wondering who difficult is:
>
> a. To put support to Pillar/Markdown inside text panes (something similar
> to the "smalltalkCode" message for showing Smalltalk in text panes but with
> "pillarCode" or "markdownCode" (or some dictionary with the #syntax keyword
> and the language as a value).
>
>
>
>  That is precisely what already happened. If you load the code, you can take
> a look at the FileReference>>gtInspectorPillarIn: method to see how to
> specify the presentation.
>
>
>
>
>  b. To execute some parts of the code, for example the ones that are inside
> "[[[" "]]]" while the cursor is there, so we could not only preview
> imagages, but also execute code for visualizations or other computations
>
>
>
>  Exactly. That should definitely be a direction. We need to experiment here
> with the exact semantics. For example, you will not always want to execute
> the code. Or not all code is meant to be executed.
>
>
>
>
>  c. The ability to support drag and drop to files to the tree (a Glamorous
> Tree) and get some kind of node pointing to that file.
>
>
>
>  That is indeed something I would want as well. For example, we should be
> able to drag and drop a pier file from the outside and spawn an editor on
> it.
>
>
>
>
>
>  d. Tha ability to preview thumbnail images in a similar way of the
> "contextual places" for printing described on your post at [2]
>
> [2] http://www.humane-assessment.com/blog/rethinking-print-it-in-pharo
>
>  Yes. This will likely come soon :)
>
> e. The hability to show a preview of the pdf/html in an emergent lateral
>
>
>  panel in a simlar way to what TeXStudio or TeXmaker do[3]
>
> [3] http://www.xm1math.net/texmaker/texmakertop_big.png
>
>
> I do not know how to do it at this time. For this purpose, we would need to
> be able to embed a browser in a Pharo UI, and I am not aware of how to do it
>
>
>
> Maybe...
>
> http://www.i-programmer.info/news/136-open-source/7433-google-open-sources-pdf-software-library.html
>
> cheers -ben
>
>
>So here I put my other ideas about "bringing liveliness to documentation"
> as you said and I would like to build them together.
>
>
>
>  Great. Please keep experimenting and keep us posted.
>
> Cheers,
> Doru
>
>
>
>
>
>  Cheers,
>
> Offray
>
> Ps: In the other threads I'm asking about how to advance in the outliner
> metaphor for live doc writing on Pharo/Moose/Roassal. I'll keep you posted.
>
> On 09/07/2014 08:41 AM, Tudor Girba wrote:
>
>
>
>  Hi,
>
> Documentation is important. To make it more likely and more enjoyable for
> people
> to write more of it, I teamed up with Andrei and Jan to build up support
> for
> Pillar in the GTInspector.
>
> The current solution brings the following:
> - Pillar specific syntax highlighting including Shout highlighting for
> code snippets
> - Embedded files validation and preview possibility
> - Quick browsing of Pillar book projects when inspecting the book folder
> - Class comment rendering using Pil

Re: [Pharo-users] [ann] pillar support in gtinspector

[Tudor Girba]

Hi,



> > Great. Please keep experimenting and keep us posted.
>
> Well I have redefined my immediate goal for the next experiment as just
> updating an object from a text pane even if this is not automatic (as I
> said in the proper thread automatic updating is not working). So, how can I
> get the current content of a text pane and send it as an argument for
> updating an object value?
>
>   With your post, I'm wondering who difficult is:
>>
>>  a. To put support to Pillar/Markdown inside text panes (something
>> similar to
>>  the "smalltalkCode" message for showing Smalltalk in text panes but
>> with
>>  "pillarCode" or "markdownCode" (or some dictionary with the #syntax
>> keyword
>>  and the language as a value).
>>
>>
>> That is precisely what already happened. If you load the code, you can
>> take a
>> look at the FileReference>>gtInspectorPillarIn: method to see how to
>> specify the
>> presentation.
>>
>
> I will as soon as I can load humane-assessment.com, to see your blog post
> again. In fact is usual for me not being able to load this site or Moose's
> ones on a regular basis (last time when I was trying to show this
> technology to a friend). If your have any possibility to consider another
> more stable hosting that would be nice for newcomers. Digital Ocean (I have
> not any affiliation with them) has been a nice solution for my for only USD
> $5 per month.


Indeed, I have some problems with my server. I am not yet sure where the
problem lies (the server itself or the provider). I restarted the server
now and I hope it will be better for a while.


>
>
>   b. To execute some parts of the code, for example the ones that are
>> inside
>>  "[[[" "]]]" while the cursor is there, so we could not only preview
>>  imagages, but also execute code for visualizations or other
>> computations
>>
>>
>> Exactly. That should definitely be a direction. We need to experiment
>> here with
>> the exact semantics. For example, you will not always want to execute the
>> code.
>> Or not all code is meant to be executed.
>>
>
>
> Well for me that would be a human decision always and by default disabled.
> What I was thinking was more inline with IPython's notebook behaviour that
> executes a code cell with a shortcut. Would be nice to have a shortcut for
> executing code inside "[[[" "]]]" blocks if the cursor is inside them.


Indeed, this is the first thing that popped in my mind as well. The problem
is that often people use the code inside [[[ ]]] for incomplete snippets as
well. So, it can actually be problematic to find the real code to run. At
least in the current books.


>
>   c. The ability to support drag and drop to files to the tree (a
>> Glamorous
>>  Tree) and get some kind of node pointing to that file.
>>
>>
>> That is indeed something I would want as well. For example, we should be
>> able to
>> drag and drop a pier file from the outside and spawn an editor on it.
>>
>
> Yes.
>
>   d. Tha ability to preview thumbnail images in a similar way of the
>>  "contextual places" for printing described on your post at [2]
>>
>>  [2] http://www.humane-assessment.__com/blog/rethinking-print-it-
>> __in-pharo
>>  > >
>>
>> Yes. This will likely come soon :)
>>
>
> Nice! Keep us posted.
>
>
>   e. The hability to show a preview of the pdf/html in an emergent
>> lateral
>>  panel in a simlar way to what TeXStudio or TeXmaker do[3]
>>
>>  [3] http://www.xm1math.net/__texmaker/texmakertop_big.png
>>  
>>
>>
>> I do not know how to do it at this time. For this purpose, we would need
>> to be
>> able to embed a browser in a Pharo UI, and I am not aware of how to do it
>>
>>
> I would think in something like executing a browser inside a VNC client
> that can be shown inside Pharo. AFAIK that's the way that Open Croquet,
> Teleplace and other Smalltalk 3D worlds use to execute and show desktop
> apps inside the worlds. I imagine that something similar can be done in a
> Glamorous Toolkit pane.
>

Would you be interested in producing a prototype in Morphic?

Cheers,
Doru



>
> Cheers,
>
> Offray
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] Workshop on Visual Data Narratives using Roassal/Pharo in our local hackerspace in Bogotá Colombia

[Tudor Girba]

Very nice initiative!

Doru

On Tue, Sep 9, 2014 at 9:43 PM, Alexandre Bergel 
wrote:

> This is excellent!
>
> Just to let you know, if you need to do a demo of Roassal, you have here
> the video a an easy to do demo: https://vimeo.com/94724841
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> On Sep 9, 2014, at 12:27 PM, Offray Vladimir Luna Cárdenas <
> off...@riseup.net> wrote:
>
> Hi,
>
> This is just a short mail to let you know whats happening here on the
> Pharo/Roassal front. We will be starting our workshops on what we I call
> Visual Data Narratives. Details (in Spanish) here:
>
> http://hackbo.co/hackboweb/eventos/evento/338
>
> Cheers,
>
> Offray
>
> ps: I will show the Moose outliner, in its alpha stage. Hopefully the
> threads where I ask how to solve the problems will move a little more and
> we will be able to integrate this to the workshops memories building.
>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] Helvetica for Pharo 3/4

[Tudor Girba]

Hi Udo,

Not yet, but the good news is that both the ability to customize both the
compiler and the debugger are now a reality which means that Helvetia
should be much easier to implement.

This should definitely be a topic of high interest.

Cheers,
Doru


On Sat, Sep 13, 2014 at 11:58 AM, Udo Schneider <
udo.schnei...@homeaddress.de> wrote:

> All,
>
> Is there something similar to Helvetica (http://scg.unibe.ch/research/
> helvetia) for Pharo 3/4? I'd like to integrate non-ST code into the
> environment and reuse the existing toolset.
>
> Thanks,
>
> Udo
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] [ANN] Easy I18N for Pharo

[Tudor Girba]

Nice job! And nice doc!

Thank you.

Doru

On Mon, Sep 15, 2014 at 11:18 PM, Torsten Bergmann  wrote:

> I just refer to my original announcement: "Need an EASY translation
> framework for your Pharo application with NO EXTERNAL dependency?"
>
> That's it. Nothing fancy. Nothing more. Only a simple project. You can -
> but must
> not use it and I did not announce it as a GetText replacement. ;)
>
> With "I18N" there is no need to externally set up other tools, by default
> no playing
> with files. One can manage and version the translation with the code. It
> is open to
> the format and I do not have to reinstall external tools when I switch
> between
> computers. Start up Pharo and off I go. But this is specific to me and
> maybe
> different for others.
>
> If it gets complicated one can always switch to GetText or other
> solutions. Look at the
> webframeworks - we have Teapot, Aida, Seaside, ... so let the users decide
> what
> he wants to use.
>
> And GetText is not the only format. Look at Java - there you have messages
> and
> message property files or *.resx from .NET world. In I18N I can use them
> as source as well
> if I like and they are also not uncommon in translation (offices) and have
> nice
> tool support too.
>
> Hilaire wrote:
> >For DrGeo this is a show stopper.
>
> As I said it depends on the needs and you may be right for Dr. Geo (or
> other
> Pharo based applications).
>
> From the discussion I think we can agree that it would be good to also
> have good
> Pharo support for GetText. And then lets talk about the IMHO currently
> horrible
> state of GetText and how to fix it:
>
>  1. Why is "GetText" not easily loadable from the config browser? If we
> want people to find and use it we should make it accessible.
>
>  2. When you google for "Pharo" and "GetText" you will find
> https://code.google.com/p/seaside/wiki/Gettext as the first match.
>
> The page is outdated, points to the old repository on SqueakSource
> http://www.squeaksource.com/PharoNonCorePackages/ and even that
> page does not include a hint that meanwhile the package moved to STHub.
>
>  3. Also the new hosting on the STHub page
> http://smalltalkhub.com/#!/~PharoExtras/Gettext
> seems broken, it includes the following comment:
>
>   "Migrated from PharoNonCorePackages. Should be adapted to Pharo2.0"
>
>  Outdated comment or not usable in Pharo 3.0/4.0?
>
>  4. The last version there is Gettext-HilaireFernandes.33, that is the one
> that is
> also included in Dr. Geo. The code should be updated as
>
>   a) it includes a reference to missing class "MethodReference" in
>  #appendVocabulary:domains:
>   b) the  NaturalLanguageTranslator>>cleanUp method references a class
> variable that is not there
>
> Any takers?
>
>  5. Writing a simple docu for I18N on STHub took me only a few minutes
> using markdown and
> https://stackedit.io. (Pillar and PillarHub provide the same, but
> STHub does not support it).
>
> So why not write a similar docu for GetText including code snippets
> and all the knowledge that
> seems to be there already from using it...
>
> Bye
> T.
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] STON: Metadata of text and yaml translations

[Tudor Girba]

Hi,

In your case, you probably do not need to store text (this is what gets in
the #text port) but the string correspondent. Just use "text asString"
before you store the updated text in your object.

Cheers,
Doru



On Wed, Sep 17, 2014 at 9:02 PM, Offray Vladimir Luna Cárdenas <
off...@riseup.net> wrote:

> Hi Sven,
>
>
> On 09/17/2014 01:30 PM, Sven Van Caekenberghe wrote:
>
>> Offray,
>>
>> On 17 Sep 2014, at 18:50, Offray Vladimir Luna Cárdenas <
>> off...@riseup.net> wrote:
>>
>>  Hi,
>>>
>>> Finally, with help in the Moose mailing list (thanks Doru!), I have
>>> automatic update of nodes in my outliner, and its working pretty well.
>>>
>>
>> It is good that you are making progress.
>>
>>
> Thanks, and thanks too for your quick answer.
>
>  I'm using STON for persistence and I see that when I update a node body
>>> content I got a lot of metadata on the text like runs, text font, text
>>> color, lastIndex, lastOfset. For reference I have attached two files,
>>> test.1.ston which is the original outline with no updates on nodes and
>>> test.2.ston which contains the updated nodes with metadata.
>>>
>>
>> 0. The goal of STON is to produce a faithful, textual, somewhat readable,
>> representation of an object graph (with object sharing and circular
>> references) that can be read to recreate the same object. JSON was the
>> starting point, the inspiration, but JSON is too limited to implement the
>> stated goal.
>>
>>  So my questions are:
>>>
>>> 1. There is any way to exclude the text metadata or to select the
>>> "deepness" of the exportation, including just the content of the text, but
>>> not the metadata of it?
>>>
>>
>> You can override/reimplement #toSton: and #fromSton: (check the other
>> implementors) to customize how your objects are handled.
>>
>> Looking at your example, I don't really see the problem, you used Text
>> instances, so they are serialized as such. This way, potential styling is
>> preserved.
>>
>>
> Yes, there is no problem and preserving text styling is a good think. I
> was just curious.
>
>  2.  I see that there is a way to export from STON to JSON. There are
>>> plans to implement something like YAML[1] export? If not, which would be a
>>> good approach to explore the existing code on STON-Core and implement this?
>>>
>>
>> No, that is not a goal/objective at all, there is no framework for that.
>> The JSON thing is a hack 'because it could be done', it cannot support the
>> stated goal.
>>
>>  3. I have seen that text string containing a carriage return are stored
>>> with "\r" character in them, there is any way to make the text be stored
>>> containing actual carriage returns?
>>>
>>
>> STONWriter will escape all dangerous characters by default and this is
>> not optional (right now). You are however free to use those characters in
>> strings, it should work as expected with STONReader.
>>
>>  From your earlier questions I infer that you want to turn STON in some
>> kind of literal programming language. This is quite far from the original
>> goal. You are of course free to use STON as inspiration or building block.
>>
>>
> My idea is to create some kind of Open/Garage/Citizen Science Notebook for
> interactive documentation and visualization combining Pharo/Roassal/Moose
> and I want to use STON or  YAML for storing and sharing that notebooks. The
> inspiration comes from tools like Leo Editor[1] and IPython Notebook[2] and
> Freemind/Docear[3] and some other ideas that I have not seeing elsewhere
> (yet ;-)).
>
> [1] http://leoeditor.com/
> [2] http://ipython.org/notebook.html
> [3] https://www.docear.org/
>
> Despite of times when I can not advance as fast as I would like or
> understand things better, is has been quite a pleasure working with Pharo
> communities and tools.
>
> Thanks again,
>
> Offray
>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] Where pharo stores its selfies?

[Tudor Girba]

Typically, in the same folder where the image resides.

Doru

On Fri, Sep 19, 2014 at 1:01 AM,  wrote:

> Hi,
>
> I'm taking somescreenshots of Pharo using the functionality provided by
> Pharo itself to make this. It seems that screenshot is properly saved, but
> there is no indication about where is stored. Could someone point me the
> place?
>
> Thanks,
>
> Offray
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] i "am" back ...

[Tudor Girba]

Welcome back!

Doru

On Fri, Sep 19, 2014 at 2:07 PM, Mayuresh Kathe  wrote:

> hello all,
>
> i had to do it.
> after listening to everybody's comments about my questions to the list, i
> went out and checked on the current state of squeak and self.
>
> looks like squeak and self definitely need a lot of attention from
> experienced developers and visionaries.
>
> since i don't fall squarely in either category, it would be best to work
> with pharo.
>
> also, as someone had mentioned, almost all smalltalk systems have diverged
> too much from the st-80 specification, so why not go for pharo which is so
> highly polished already and is being constantly improved!
>
> so here i am, back in pharo land.
>
> ~mayuresh
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] [ANN] Test Coverage with Hapao

[Tudor Girba]

What do you mean?

Doru

On Sun, Sep 21, 2014 at 2:42 PM, Trygve Reenskaug 
wrote:

>
> On 20.09.2014 14:51, stepharo wrote:
>
> This is cool I blog about it.
> Now pay attention class categories will not exist in the future.
>
> Stef
>
> Any ref to this development?
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] [ANN] Test Coverage with Hapao

[Tudor Girba]

Class categories are system categories :).

Since Pharo 3.0, they are replaced with RPackage. They are still around at
the moment as a backup system, but almost everything in the image should
now work through RPackage. The difference between the two is that while
system categories are awkward strings, RPackages are explicit objects.

To learn more, you can inspect for example:
RPackageOrganizer default packages

Cheers,
Doru

On Sun, Sep 21, 2014 at 5:33 PM, Trygve Reenskaug 
wrote:

>  Doru,
> "*Now pay attention class categories will not exist in the future.*"
> I already know about system categories (categories of classes) and method
> categories within a class.
> I understood you to mean system categories.
> What are class categories and why will they be removed?
> --Trygve
>
>
>
> On 21.09.2014 15:36, Tudor Girba wrote:
>
> What do you mean?
>
>  Doru
>
> On Sun, Sep 21, 2014 at 2:42 PM, Trygve Reenskaug 
> wrote:
>
>>
>> On 20.09.2014 14:51, stepharo wrote:
>>
>> This is cool I blog about it.
>> Now pay attention class categories will not exist in the future.
>>
>> Stef
>>
>>  Any ref to this development?
>>
>
>
>
>  --
> www.tudorgirba.com
>
>  "Every thing has its own flow"
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] [ANN] Test Coverage with Hapao

[Tudor Girba]

It is :)

Doru

On Sun, Sep 21, 2014 at 8:28 PM, Trygve Reenskaug 
wrote:

>  Thanks. Looks like a powerful improvement.   --Trygve
>
>
> On 21.09.2014 19:34, Tudor Girba wrote:
>
> Class categories are system categories :).
>
>  Since Pharo 3.0, they are replaced with RPackage. They are still around
> at the moment as a backup system, but almost everything in the image should
> now work through RPackage. The difference between the two is that while
> system categories are awkward strings, RPackages are explicit objects.
>
>  To learn more, you can inspect for example:
> RPackageOrganizer default packages
>
>  Cheers,
> Doru
>
> On Sun, Sep 21, 2014 at 5:33 PM, Trygve Reenskaug 
> wrote:
>
>>  Doru,
>> "*Now pay attention class categories will not exist in the future.*"
>> I already know about system categories (categories of classes) and method
>> categories within a class.
>> I understood you to mean system categories.
>> What are class categories and why will they be removed?
>> --Trygve
>>
>>
>>
>> On 21.09.2014 15:36, Tudor Girba wrote:
>>
>> What do you mean?
>>
>>  Doru
>>
>> On Sun, Sep 21, 2014 at 2:42 PM, Trygve Reenskaug 
>> wrote:
>>
>>>
>>> On 20.09.2014 14:51, stepharo wrote:
>>>
>>> This is cool I blog about it.
>>> Now pay attention class categories will not exist in the future.
>>>
>>> Stef
>>>
>>>  Any ref to this development?
>>>
>>
>>
>>
>>  --
>> www.tudorgirba.com
>>
>>  "Every thing has its own flow"
>>
>>
>>
>
>
>  --
> www.tudorgirba.com
>
>  "Every thing has its own flow"
>
>
> --
>
> Trygve Reenskaug  mailto: tryg...@ifi.uio.no
> Morgedalsvn. 5A   http://folk.uio.no/trygver/
> N-0378 Oslo http://fullOO.info
> Norway Tel: (+47) 22 49 57 27
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] Loading PetitParser loads a hell of a lot of things... is there a terser version?

[Tudor Girba]

Hi,

The dependencies are needed for the UI. If you can live without the UI, you
can load the 'Core' group from the configuration.

Cheers,
Doru



On Thu, Sep 25, 2014 at 2:07 PM, p...@highoctane.be 
wrote:

> I am loading PetitParser in my image but it takes a lng time to load
> and below is what I see in my Jenkins console.
>
> Build for that step starts at 13:48:51 and ends at 14:03:15. Phew!
>
> Also a couple errors in loading examples.
>
> What is recommended to use to not have all of this? I just need the parser
> and tools to browse the grammars.
>
>
> [34m13:48:51 :  --> loadPetitParser step starting
>
> Loading 1.6-baseline of ConfigurationOfPetitParser...
> Fetched -> ConfigurationOfGlamour-AndreiChis.158 ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/ ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/
> Loaded -> ConfigurationOfGlamour-AndreiChis.158 ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/ ---
> /var/lib/jenkins/jobs/CXP Frontend/workspace/package-cache
> Fetched -> PetitParser-JanKurs.247 ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/ ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/
> Fetched -> PetitTests-JanKurs.59 ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/ ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/
> Fetched -> PetitAnalyzer-DiegoLont.46 ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/ ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/
> Fetched -> PetitSmalltalk-JanKurs.71 ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/ ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/
> Fetched -> PetitCSV-tg.7 ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/ ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/
> Fetched -> PetitJson-DamienCassou.8 ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/ ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/
> Fetched -> PetitMSE-AndreHora.21 ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/ ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/
> Fetched -> PetitManifestMf-tg.9 ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/ ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/
> Fetched -> PetitRegex-JanKurs.29 ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/ ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/
> Fetched -> PetitXml-JanKurs.36 ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/ ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/
> Fetched -> PetitXPath-EstebanLorenzano.7 ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/ ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/
> Fetched -> PetitIslands-JanKurs.9 ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/ ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/
> Fetched -> Factorial-Language-lr.6 ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/ ---
> http://smalltalkhub.com/mc/Moose/PetitParser/main/
> Project: Glamour development [2.91-baseline]
> Fetched -> ConfigurationOfGraphET-TudorGirba.8 ---
> http://smalltalkhub.com/mc/ObjectProfile/GraphET/main/ ---
> http://smalltalkhub.com/mc/ObjectProfile/GraphET/main/
> Loaded -> ConfigurationOfGraphET-TudorGirba.8 ---
> http://smalltalkhub.com/mc/ObjectProfile/GraphET/main/ ---
> /var/lib/jenkins/jobs/CXP Frontend/workspace/package-cache
> Fetched -> ConfigurationOfRubric-AndreiChis.7 ---
> http://smalltalkhub.com/mc/AlainPlantec/Rubric/main/ ---
> http://smalltalkhub.com/mc/AlainPlantec/Rubric/main/
> Loaded -> ConfigurationOfRubric-AndreiChis.7 ---
> http://smalltalkhub.com/mc/AlainPlantec/Rubric/main/ ---
> /var/lib/jenkins/jobs/CXP Frontend/workspace/package-cache
> Fetched -> ConfigurationOfRoassal-StephaneDucasse.1195 ---
> http://smalltalkhub.com/mc/ObjectProfile/Roassal/main/ ---
> http://smalltalkhub.com/mc/ObjectProfile/Roassal/main/
> Loaded -> ConfigurationOfRoassal-StephaneDucasse.1195 ---
> http://smalltalkhub.com/mc/ObjectProfile/Roassal/main/ ---
> /var/lib/jenkins/jobs/CXP Frontend/workspace/package-cache
> Fetched -> Glamour-Announcements-TudorGirba.7 ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/ ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/
> Fetched -> Glamour-Helpers-AndreiChis.35 ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/ ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/
> Fetched -> Glamour-Core-AndreiChis.277 ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/ ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/
> Fetched -> Glamour-Presentations-TudorGirba.157 ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/ ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/
> Fetched -> Glamour-Browsers-TudorGirba.104 ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/ ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/
> Fetched -> Glamour-Examples-StephanEggermont.284 ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/ ---
> http://smalltalkhub.com/mc/Moose/Glamour/main/
> Project: Roassal for Glamour devel

Re: [Pharo-users] [Pharo-dev] Data Analysis in Pharo

[Tudor Girba]

Indeed, this is nice!

It is for this reason that Moose is a data analysis platform, and what we
see now is just only tip of the iceberg, Once these tools get embedded deep
in the environment the potential simply explodes.

Cheers,
Doru


On Sun, Sep 28, 2014 at 8:27 PM, Alexandre Bergel 
wrote:

> [sorry for the cross-post]
>
> Dear all,
>
> There has been quite some work around analyzing non-software related data.
> The teams of Serge, Thierry and Noury have been doing wonderful things. I
> am not sure you are aware of this, but I found this a nice achievement of
> what our community can do.
>
> Using sensors networks in Jakarta, Indonesia, to monitor floods.
>
> https://www.facebook.com/ObjectProfile/photos/a.341189379300999.82969.340543479365589/706190742800859/?type=1
>
> CAR: Components, Agents, and Robots
> https://www.facebook.com/ObjectProfile/posts/704750642944869
>
> Fantastic model from the Vietnam crew working on Ebola spreading
>
> https://www.facebook.com/ObjectProfile/photos/a.341189379300999.82969.340543479365589/704650679621532/?type=1
>
> Another picture from the crew studying Ebola.
>
> https://www.facebook.com/ObjectProfile/photos/a.341189379300999.82969.340543479365589/704304912989442/?type=1
>
> Ebola fatalities in Guinea.
>
> https://www.facebook.com/ObjectProfile/photos/a.341189379300999.82969.340543479365589/703876539698946/?type=1
>
> Visualizing Astronomy pictures
> https://www.facebook.com/ObjectProfile/posts/702429986510268
>
> Visualization of Network Latency by Leonel Merino
> http://t.co/xJN6qk1AEG
>
> Being this work, there is quite some sweat. This work does not happen
> randomly, and their authors deserve our encouragements.
>
> I do not know if this make sense to crosspost all these urls (looks like a
> spam isn’t it?) but I am really happy to see all that happening.
>
> Cheers,
> Alexandre
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] UI testing

[Tudor Girba]

Hi,

Glamour comes with an extensive Morphic test suite.

You can check it here in the subclasses of GLMMorphicTest. The superclass
also has a number of utility methods. The checking is done via excellent
additions to Morphic (I believe by Sean).

See for example this:
GLMTextMorphicTest>>testAcceptKeyCanBeOverriden
| composite textMorph overriden |
overriden := false.
composite := GLMCompositePresentation new with: [ :a | a text act: [ :text
| overriden := true ] on: $s entitled: 'Override'].
window := composite openOn: 4.
textMorph := self find: PluggableTextMorph in: window.
textMorph simulateClick.
self simulateKeyStroke: $s command.
self simulateKeyStroke: $s control.
self simulateKeyStroke: $s alt.
self assert: overriden.

Cheers,
Doru



On Tue, Sep 30, 2014 at 11:00 AM, Usman Bhatti 
wrote:

> Hi all,
>
> Is there anything in Pharo that supports UI testing?
> What I would like to achieve is to be able to simulate a click, select a
> menu item, input some text in text fields, Ok/Cancel button click, and some
> other basic task for the automation of my tests.
>
> With Glamour, I can simulate transmissions programatically and then test
> for the display values in the presentations or dig the resulting morph
> structure to test for specific information. The problem with dialog boxes
> is that once launched, I cannot perform anything in the system because my
> test code is active only when dialog boxes get their intended input and are
> validated.
>
> So, if there is anything for simulating testing "scenarios" (click on
> second button -> select third menu item -> fill up text field -> select
> color -> ok button -> test fourth PanelMorph in the window ), it would be
> really helpful and make my testing much more productive.
>
> regards,
>
> usman
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] Installing GToolkit

[Tudor Girba]

Hi Evan,

The instructions are a bit wrong. It should be "activateWithoutSaving"
instead of "activate".

The GTImageSetupCommandLineHandler does more default settings. Just take a
look at the activateWithoutSaving method and pick what you want, or use the
script that Phil suggested only to install the tools.

But, what do you mean when you say that the Playground is not working?

Cheers,
Doru


On Sat, Oct 4, 2014 at 8:07 PM, Evan Donahue  wrote:

> Hello,
>
> I am trying to check out GTPlaygroundl, but I can't seem to get it working
> and was wondering if anyone had any idea what I might be overlooking.
>
> I download a new image with curl get.pharo.org | bash
> I run, from http://www.humane-assessment.com/blog/installing-gtoolkit
>
> Gofer new
>  smalltalkhubUser: 'Moose' project: 'GToolkit';
>  configuration;
>  loadDevelopment.
> #GTImageSetupCommandLineHandler asClass new activate
>
> It loads for a while and then the image closes. When I open it again the
> background is white and my settings have been wiped. The playground does
> appear, but it doesn't seem to work properly (there seems to be no way to
> advance the miller columns). Am I looking at the wrong installation
> information?
>
> Thanks,
> Evan
>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] [Pharo-dev] Artefact documentation is now in english

[Tudor Girba]

Thanks!

Doru

On Sun, Oct 12, 2014 at 7:36 PM, stepharo  wrote:

> Hi guys
>
> I finished the translation of the chapter on Artefact the pdf generator
> library developed by O. Auverlot and G. Larcheveque.
>
> https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/
> lastSuccessfulBuild/artifact/Artefact/Artefact.pillar.pdf
>
> Stef
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] ZipFileMember>>contentStream has leading characters

[Tudor Girba]

What is the code that you use?

Doru

On Mon, Oct 13, 2014 at 1:31 AM, DiegoSanchez 
wrote:

> Hi everybody!  This is my first post and I'm posting this question after
> going around this forum without finding answer for my question.  I couldn't
> wrap my mind around it.
>
> Here is the issue (in fact it is not a issue, classes work fine).
>
> I want to uncompress a zip file and file in the content of one of the file
> included in zip file.  For instance:
> The file 'tp1.zip' contains just one file inside it: 'test.st'.
>
> Once I uncompressed it, using code bellow:
>
>
>
> I found that file stream has a set of leading characters which cannot be
> interpreted by *CodeInterpreter*.
>
> Here you will fine these leading characters:
>
> /Hexa characters/
> *ef  bb  bf *
>
> /Ascii characters/
> *ef  bb  bf *
>
> Indeed, this leading characters are written by the fileOut process and it's
> ok (those are magic number which depend on the SO) but I don't know how to
> skip it for CodeInterpreter to be able fileIn this file.
>
> My first solution was skipping this characters through the use of
> /Stream>>next: 4/. But I'm looking for a much portable solution.
>
> Somebody went through this problem?
>
> Thanks for help in advance.
> DiegoS
>
>
>
> --
> View this message in context:
> http://forum.world.st/ZipFileMember-contentStream-has-leading-characters-tp4784238.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] ZipFileMember>>contentStream has leading characters

[Tudor Girba]

You are likely referring to the issue reported here:
https://pharo.fogbugz.com/f/cases/12826/Zip-FileSystem-does-not-work

This should work now in the latest Pharo 4.0. If you are using Pharo 3.0,
loading the slice manually from the Pharo40Inbox should fix the issue as
well.

What version are you using?

Cheers,
Doru



On Mon, Oct 13, 2014 at 1:23 PM, Diego Sánchez 
wrote:

> | zipper file |
>   zipper := ZipArchive new readFrom: 'tp1.zip'.
>
> "file contains test.st"
>   file := zipper members at: 1.
>   
>   "file contentStream returns the stream with file's information 
> uncompressed"
>
>
> On 13 October 2014 08:22, Diego Sánchez  wrote:
>
>> doitFromStream
>>  | zipper file |
>>  zipper := ZipArchive new readFrom: '/Users/diego/tp1-95195.zip'.
>>  file := zipper members at: 2.
>>  
>>  "file contentStream returns the stream with file's information 
>> uncompressed"
>>
>>
>> On 13 October 2014 08:15, Tudor Girba  wrote:
>>
>>> What is the code that you use?
>>>
>>> Doru
>>>
>>> On Mon, Oct 13, 2014 at 1:31 AM, DiegoSanchez 
>>> wrote:
>>>
>>>> Hi everybody!  This is my first post and I'm posting this question after
>>>> going around this forum without finding answer for my question.  I
>>>> couldn't
>>>> wrap my mind around it.
>>>>
>>>> Here is the issue (in fact it is not a issue, classes work fine).
>>>>
>>>> I want to uncompress a zip file and file in the content of one of the
>>>> file
>>>> included in zip file.  For instance:
>>>> The file 'tp1.zip' contains just one file inside it: 'test.st'.
>>>>
>>>> Once I uncompressed it, using code bellow:
>>>>
>>>>
>>>>
>>>> I found that file stream has a set of leading characters which cannot be
>>>> interpreted by *CodeInterpreter*.
>>>>
>>>> Here you will fine these leading characters:
>>>>
>>>> /Hexa characters/
>>>> *ef  bb  bf *
>>>>
>>>> /Ascii characters/
>>>> *ef  bb  bf *
>>>>
>>>> Indeed, this leading characters are written by the fileOut process and
>>>> it's
>>>> ok (those are magic number which depend on the SO) but I don't know how
>>>> to
>>>> skip it for CodeInterpreter to be able fileIn this file.
>>>>
>>>> My first solution was skipping this characters through the use of
>>>> /Stream>>next: 4/. But I'm looking for a much portable solution.
>>>>
>>>> Somebody went through this problem?
>>>>
>>>> Thanks for help in advance.
>>>> DiegoS
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://forum.world.st/ZipFileMember-contentStream-has-leading-characters-tp4784238.html
>>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Every thing has its own flow"
>>>
>>
>>
>>
>> --
>> Saludos
>> DiegoS
>>
>> --
>>
>> Diego Sanchez
>> [image: http://]about.me/sanchez.diego
>> <http://about.me/sanchez.diego?promo=email_sig>
>>
>>
>>
>>
>
>
> --
> Saludos
> DiegoS
>
> --
>
> Diego Sanchez
> [image: http://]about.me/sanchez.diego
> <http://about.me/sanchez.diego?promo=email_sig>
>
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] Trouble opening large files

[Tudor Girba]

Hi,

If I understand correctly, the failure occurs while navigating in the
"Items" presentation.

I cannot reproduce this problem because I do not have enough disk space for
such a large file :). But, could you do the following and let me know what
the outcome is:

'path/to/your/large/file.xml' asFileReference humanReadableSize

?

Cheers,
Doru



On Tue, Oct 14, 2014 at 2:27 AM, Evan Donahue  wrote:

> Hello, I've run into some odd behavior and wanted to check whether I might
> be missing something:
>
> I have downloaded a copy of the english wikipedia as an xml file and am
> hoping to (sax) parse it. However, I can't even seem to get pharo to
> recognize that the file exists.
>
> If I open FileSystem disk root in the playground and naigate, attempting
> to enter the folder containing the (57G) xml file fails with
> "MessageNotUnderstood: False>>humanReadableSIByteSize." Likewise if I get a
> FileReference with FileSystem disk root / 'path' / 'to' / 'file' then self
> exists returns false and the parser fails.
>
> Am I doing something wrong? Should I be able to do this?
>
> The version number is #40283
>
> Thanks,
> Evan
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] [Ann] Phratch 4.0

[Tudor Girba]

This is a great addition to the Pharo ecosystem.

Thank you very much!

Doru

On Fri, Oct 17, 2014 at 11:48 AM, jannik laval 
wrote:

> Phratch 4.0 is out of the box !
>
> Phratch 4.0 is cleaner, faster and more stable than phratch 3.0.
>
> After the version 3.0 that was a release for usability and stability,
> phratch 4.0 is released to prepare the future.
>
> The new features are:
>
> - phratch is more modular, eg having a kernel and lots of addons.
> - cleaning a lot the source code
> - customizable environment
> - each block can be made visible or invisible
> - each category can be made visible or invisible
> - it is possible to add translation for addons with the pragma
>  in the class PhratchTranslator. This make the
> translation more modular.
> - first integration of phratch with the pharo environment. Using the
> pragma at the class side of any class in Pharo make the class visible and
> usable in phratch.
> - There is a lot of things to do with phratch, you are welcome to
> contribute ! The documentation for new features will arrive soon.
>
> See you on phratch.com
>
> --
>
> ~~Jannik Laval~~
> École des Mines de Douai
> Enseignant-chercheur
> http://www.jannik-laval.eu
> http://www.phratch.com
> http://www.approchealpes.info
> http://car.mines-douai.fr/
>



-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] new Pharo Success story

[Tudor Girba]

+100

Doru

On Mon, Oct 20, 2014 at 11:41 AM, Sven Van Caekenberghe 
wrote:

>
> > On 19 Oct 2014, at 09:44, stepharo  wrote:
> >
> > Hi
> >
> > we just published a new success story: Pharo at CSOB
> >
> >http://pharo.org/success
> >
> > And yes we are interested in your sucess stories
> >
> > Stef
> >
> > PS: big thanks to Tomas and CSOB for letting us making this public.
>
> Beautiful! Great work.
>
> It is a lot of work to do a project inside such a big bank, let alone make
> a success of it. Congratulation to Tomas and the rest of his team.
>
> Sven
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] [Pharo-dev] Clickable class side example and initialize methods in Pharo 4.0

[Tudor Girba]

Hi Torsten,

Thanks for this. This is indeed the way to go.

Just to let you know, the example infrastructure is also being developed in
the context of GT, so we have a healthy interest overlap which is great.
Only in our case, the discovery of the example happens through an 
pragma. Would it be possible to change your slice to use this pragma
instead of the example* convention?

Cheers,
Doru



On Wed, Oct 22, 2014 at 9:19 AM, Torsten Bergmann  wrote:

> One addition I implemented for Nautilus is that one can run examples
> directly
> in the browser just by clicking on class side example methods icons.
>
> See
> https://pharo.fogbugz.com/f/cases/13892/Example-methods-should-be-runnable-in-Nautilus
> for a picture.
>
>
> SO PLEASE: WHEN YOU PROVIDE EXAMPLES IN CLASSES PLEASE PUT THEM ON THE
> CLASS SIDE
>AND LET THE SELECTOR START WITH "example".
>
> This way people will easily see that it is an example and can run them.
> Additionally it
> would help to put them into a category like "examples". So be a good
> citized and
> provide not only class comments but also examples for others to study.
>
>
> Side note:
> ==
> It is also possible to click on the icon of class side initialize methods
> so the
> class get reinitialized (after a confirmation to avoid false clicking).
>
>
> https://pharo.fogbugz.com/f/cases/13894/Class-side-initialize-methods-should-be-runnable-in-Nautilus
>
> Both issues are already integrated.
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] [Pharo-dev] Clickable class side example and initialize methods in Pharo 4.0

[Tudor Girba]

You are welcome. You should expect more in this direction.

Doru

On Wed, Oct 22, 2014 at 11:02 AM, kilon alios  wrote:

> very good feature that I was completely unaware of. I have actually
> examples in my Ephestos project that are at class side but I use ex instead
> of example. This will come very handy for my users thanks :)
>
> On Wed, Oct 22, 2014 at 11:43 AM, Tudor Girba 
> wrote:
>
>> Hi Torsten,
>>
>> Thanks for this. This is indeed the way to go.
>>
>> Just to let you know, the example infrastructure is also being developed
>> in the context of GT, so we have a healthy interest overlap which is great.
>> Only in our case, the discovery of the example happens through an 
>> pragma. Would it be possible to change your slice to use this pragma
>> instead of the example* convention?
>>
>> Cheers,
>> Doru
>>
>>
>>
>> On Wed, Oct 22, 2014 at 9:19 AM, Torsten Bergmann  wrote:
>>
>>> One addition I implemented for Nautilus is that one can run examples
>>> directly
>>> in the browser just by clicking on class side example methods icons.
>>>
>>> See
>>> https://pharo.fogbugz.com/f/cases/13892/Example-methods-should-be-runnable-in-Nautilus
>>> for a picture.
>>>
>>>
>>> SO PLEASE: WHEN YOU PROVIDE EXAMPLES IN CLASSES PLEASE PUT THEM ON THE
>>> CLASS SIDE
>>>AND LET THE SELECTOR START WITH "example".
>>>
>>> This way people will easily see that it is an example and can run them.
>>> Additionally it
>>> would help to put them into a category like "examples". So be a good
>>> citized and
>>> provide not only class comments but also examples for others to study.
>>>
>>>
>>> Side note:
>>> ==
>>> It is also possible to click on the icon of class side initialize
>>> methods so the
>>> class get reinitialized (after a confirmation to avoid false clicking).
>>>
>>>
>>> https://pharo.fogbugz.com/f/cases/13894/Class-side-initialize-methods-should-be-runnable-in-Nautilus
>>>
>>> Both issues are already integrated.
>>>
>>>
>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] [Pharo-dev] Clickable class side example and initialize methods in Pharo 4.0

[Tudor Girba]

Hi,

I also disagree with Alex.

Examples will become tests (see the work of Markus Gaelli and Adrian Kuhn)
and they should be casually connected with the class and intention they
test or provide example for. The other thing is that examples should be
composable via code. And of course, they should be browsable.

They will be close to the class by default, but it does not mean that in
the class will be the only way. For example, we can well imagine having
helper classes for holding examples, but most classes would not need that I
think.

As for pragmas, they are a better mechanism for describing intent than a
method naming convention is. If nothing else, it lets us freedom in naming
the method.

It's true that at this point, pragmas are hard to browse, but this will not
remain like this for long :)

Cheers,
Doru


On Wed, Oct 22, 2014 at 9:14 PM, stepharo  wrote:

> I agree with Thierry but I disagree with Alex :)
> What is cool is that when you browse a widget class that you get all the
> examples for this class.
>
> Stef
>
>  I am also not a big fan of using pragmas. To me, it looks like an ad hoc
>> approach to have examples close to the class. In the same spirit: Why not
>> having tests in the same class? Would it not be cool? Of course not.
>> In Roassal we have a class for examples (similar to TestCase).
>>
>> Alexandre
>>
>>  Le 22-10-2014 à 14:51, Thierry Goubier  a
>>> écrit :
>>>
>>> Hi all,
>>>
>>> by principle, I'd be against extending so much the pragmas... from a
>>> design point of view they look like #defines and macros, that is an
>>> additional language to learn, without a correct support of the tools (no
>>> debug on pragmas, non-obvious behavior triggers, search for pragma users
>>> difficult, not documented).
>>>
>>> Alexandre, your idea of infering properties from the source code looks a
>>> lot more interesting (and with a lot more potential).
>>>
>>> Thierry
>>>
>>> Le 22/10/2014 19:38, Alexandre Bergel a écrit :
>>>
>>>> Hi!
>>>>
>>>> I have doubt that #example: will be enough in the case of Roassal.
>>>> Having a code example browser is indeed important and having a descent
>>>> way to search for the examples is also important. I am thinking to stick to
>>>> #example and infer some categories from the source code (e.g., if the
>>>> method contains a Zinc class, then it may be categorized in network).
>>>>
>>>>
>>>> Cheers,
>>>> Alexandre
>>>>
>>>>  Le 22-10-2014 à 7:38, Torsten Bergmann  a écrit :
>>>>>
>>>>> Hi Tudor,
>>>>>
>>>>> that should be easy now: look at CompiledMethod>>#isExampleMethod
>>>>> which can be adopted as needed.
>>>>>
>>>>> Checking for the  pragma could be done this way:
>>>>>
>>>>>self pragmas anySatisfy: [:pragma | pragma keyword = #example ]
>>>>>
>>>>> but we should think first if this is enough.
>>>>>
>>>>> I already proposed to not only annotate with a pragma  but
>>>>> additionally give a category.
>>>>> Like this:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> This way we can easily build an example browser for our users where
>>>>> people can go through
>>>>> their point of interest and browse the examples.
>>>>>
>>>>> Maybe we should also rethink pragmas (in Pharo 5.0?) in general to be
>>>>> more Smalltalk
>>>>> like:
>>>>>
>>>>>
>>>>>
>>>>> where Example is a real class in the system (!). One can even make it
>>>>> more explicit
>>>>> then
>>>>>
>>>>>
>>>>>
>>>>> with ExampleCategory(class)>>graphics returning a translateable
>>>>> string. People can add
>>>>> own categories and one easily knows about already available ones.
>>>>>
>>>>>
>>>>> Now that classes can have properties in Pharo 4.0 already I would like
>>>>> to see a unification
>>>>> for methods and classes here (with the general concept of an
>>>>> "Annotation" in our metamodel).
>>>>>
>>>>> In my opinion a method pragma is just a special form of annotating a
>>>>> method.
>>>>&g

[Pharo-users] [ANN] new GT features: disk memory, ws.stfx.eu sharing, closeable panes and others

[Tudor Girba]

Hi,

We are quite actively working on GT.

First of all, thanks everyone for the feedback. We take it quite seriously
and we do our best to take it into account. Please keep the discussions
flowing.

I summarized some of the things that happened recently in the playground
and inspector here:
http://www.humane-assessment.com/blog/gt-developments-endless-playground-memory-sharing-and-others/

Let us know what you think.

Cheers,
Doru

-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] FFI structs

[Tudor Girba]

That is cool.

Doru

On Thu, Oct 30, 2014 at 11:37 PM, stepharo  wrote:

>  Ronie is working on unifying all the api and proposing one syntax
> mechanism for
> - nativeBoost back-end
> - FFI
> and may be Alien
>
> The FFI situation is not good and we know we should improve it.
>
>
> On 29/10/14 20:18, Thomas Bany wrote:
>
>  Oops, sorry, I was misslead by Steph reply.
>
>  Some of the comments might still hold. For the *time: ’05:45’* code to
> work, you would need FFI to handle all the hassle of memory management and
> actually allocate the memory for 5 characters and copying it. I never used
> FFI but I doubt it does this.
>
>  Looking at FFI library, you both have ExternalAddress (for the struct
> with char*) and ExternalType (for the struct with char[5]) that you can
> use. For the later solution, it still looks like you should define a
> specific 5 bytes ArrayOf5Char type.
>
> 2014-10-29 18:34 GMT+01:00 Annick Fron :
>
>> I can’t use NativeBoost on the Raspberry, I would be glad if I could !!!
>>
>>
>> Le 29 oct. 2014 à 12:18, stepharo  a écrit :
>>
>> > did you read the NativeBoost tutorial on the PharoForTheEntreprise book?
>> > If you do please report potential mistakes so that we can improve.
>> >
>> >
>> > On 29/10/14 05:59, Annick Fron wrote:
>> >> I I have a C struct with a char*
>> >>
>> >> struct result {
>> >>  char* time }
>> >>
>> >> I define an ExternalStructure in FFI , with one field of type char*
>> (note that the syntax char [5] is not accepted ! ).
>> >>
>> >> defineFields generates the accessors time and time:
>> >>
>> >> If I use
>> >> time: ’05:45’
>> >>
>> >> I get an error.
>> >> How do I set a string value in an ExternalStructure ?
>> >>
>> >> Annick
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"