Re: [Pharo-users] Spec "bindings"

[Rob Rothwell]

On Sat, Sep 9, 2017 at 5:06 AM, Stephane Ducasse 
wrote:

> Hi Rob
>
> I discussed with peter and I hope that he has more and younger
> braincells than me. I'm *super* busy with lectures
> preparation, workshop preparation and business issues. So I would love
> to get some time to get concentrated but not before beginning of
> October at the minimum.
> May be when I am at Prague we can discuss with Peter.
>
> Stef
>
>
>
Hi Stef,

Thank you very much for the encouragement,  and good luck with all your
endeavors.  I have a huge MOOC project going on at work myself (you know
how that can be), but I will keep experimenting with this and try to be
prepared when there is some time available!

Take care,

Rob

Re: [Pharo-users] Spec "bindings"

[Rob Rothwell]

On Sat, Sep 9, 2017 at 7:11 AM, Peter Uhnak  wrote:

> Hi Rob,
>
> I'm making a note to look at your proposals and I will discuss it with
> Stef later.
>

Thanks, Peter, I appreciate any insights you can offer.  I will continue
experimenting, and just wanted to make sure I figured out how to share my
ideas during a window of opportunity I had.


> >
> > he has more and younger braincells than me
>
> But not enough connections between them. The cells just sit there alone
> and are not talking to anyone. :(
>

I can certainly relate to that! Unfortunately, some of my best thinking is
out loud trying to explain something I don't really understand to someone
else...

Take care,

Rob


>
> Peter
>
>

Re: [Pharo-users] STON: Skip Inst Var

[Sven Van Caekenberghe]

> On 9 Sep 2017, at 18:00, Sean P. DeNigris  wrote:
> 
> Sven Van Caekenberghe-2 wrote
>> Implement...
> 
> Thanks! I added this to the wiki so we don't lose track of it:
> https://github.com/svenvc/ston/wiki/Cookbook

Cool, thanks.

Re: [Pharo-users] STON: Skip Inst Var

[Sean P. DeNigris]

Sven Van Caekenberghe-2 wrote
> Implement...

Thanks! I added this to the wiki so we don't lose track of it:
https://github.com/svenvc/ston/wiki/Cookbook



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

Re: [Pharo-users] Let's prepare for Google Code-In 2017 with Pharo Consortium

[Jigyasa Grover]

Thanks Stef for your support.

I have already added you in the private repository "GCI-2017-with-Pharo", as
we need to keep prospective students away from the task list before the
program begins 

Looking forward to more ideas on the task list.

Thanks a lot.

Best
Jigyasa Grover



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] STON: Skip Inst Var

[Sven Van Caekenberghe]

> On 9 Sep 2017, at 16:11, Sean P. DeNigris  wrote:
> 
> Sven Van Caekenberghe-2 wrote
>> You would have to change the way the offending object get handled.
> 
> Any suggestions on how to do that? Is there a particularly good place to
> hook in?

Implement FileSystem class>>#stonAllInstVarNames to skip workingDirectory

Or implement/customize FileSystem>>#stonOn: and/or #fromSton: 

But if workingDirectory is an essential part of FileSystem, that would not be a 
good long term solution.

Following migrations like this is never easy/elegant.

Re: [Pharo-users] Standalone HTML Model

[Sean P. DeNigris]

Sven Van Caekenberghe-2 wrote
> not really a DSL

I disagree ;) It looks perfect!



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

Re: [Pharo-users] STON: Skip Inst Var

[Sean P. DeNigris]

Sven Van Caekenberghe-2 wrote
> You would have to change the way the offending object get handled.

Any suggestions on how to do that? Is there a particularly good place to
hook in?



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

Re: [Pharo-users] Standalone HTML Model

[Sean P. DeNigris]

Hannes Hirzel wrote
> the question is of course - is it the HTML only model you are
> interested in or is it rather a 'web document model'

Thanks for the detailed replies! Yes, you are right. I should've given more
info about my use case. I had some HTML that I was using for an email
signature for my organization. Every time we have a new officer, I would dig
out and hand edit an existing signature in a dumb text file. This worked as
far as it goes, but when I wanted to make a change to the design, I'd have
to hand edit them all. So, I thought, let's just do it automagically in
Pharo! But then I ended up with a weird hybrid approach where:
- PRO: I broke the HTML up into smaller logical pieces in Pharo methods
- CON: The individual pieces were still just dumb text (e.g. I had to read
through a string to pick out which parts belong to which
tag/attribute/inner-text)
- CON: I lost the ability to deal with the HTML in its own domain (e.g. open
it in Dreamweaver and live edit)

I reckoned that I should fully commit to one approach. Either have an HTML
template file(s) which Pharo manipulates, or break up the HTML fully into a
domain representation.

So my goal is to have something which outputs HTML suitable for an email
signature based on HTML which I already have in text/file form.



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

Re: [Pharo-users] #parseMethod:onError: isn't as obvious as expected - is it me?

[Tim Mackinnon]

Thanks for the pointer Marcus, I'll have a look - it's a fascinating area that 
I didn't know much about until now ;)

All I wanted was to not have to select specific code to do senders (& 
refactoring), as well as have better statement selection so I can more easily 
put brackets around things...

But now it dawns on me I'd like better code completion after I've already 
completed but maybe want the fuller keyword method 

Even the refactoring of local method changes shouldn't need you to save your 
method to rename a local variable or extract a statement to a variable. And I 
hate having to declare local variables painfully one by one - and I miss the 
option to detect a simple typo and correct it.

These are all things that I love in IntelliJ - and I think we have fantastic 
infrastructure to do these things too. So I'll keep plugging away at lunch 
times to see what I can do.

I've rewritten it about 3 times already ;)

Tim

Sent from my iPhone

> On 9 Sep 2017, at 08:42, Marcus Denker  wrote:
> 
> there is #parseFaultyMethod:, too. We use RBParser for syntax highlighting.
> 
> We do already have “senders” and “implementors working in the AST when using 
> Suggestions.
> 
> See SugsMenuBuilder>>#findBestNodeFor: 
> 
> in the case of non-accepted code, it uses the compiler chain with 
> #optionParseErrors (which uses parseFaultyMethod: to parse).
> 
>   context hasUnacceptedEdits
>   ifTrue: [ 
>   root := Smalltalk compiler
>   source: context code;
>   options: #(+ optionParseErrors);
>   parse.
>   context selectedClass ifNotNil: [ :theClass | root 
> methodNode methodClass: theClass ].
>   root doSemanticAnalysis ]
> 
> This works well but fails when you actually are in an error node.. for the 
> same code the “dumb” way we use
> with standard “senders of” just takes line, looks for spaces and feeds that 
> word into the “senders of”..
> 
> So to make this work better we need to combine both approaches and deal 
> better with the Error Node content.
> (e.g. trying to fix it and re-parse or just use the dumb “get the work under 
> the cursor” way as a first step).
> 
>   Marcus
> 
>> On 8 Sep 2017, at 03:43, Tim Mackinnon  wrote:
>> 
>> Damn you smalltalk… you suck me in to little side problems….
>> 
>> RBParser is actually a lot more flexible than I had realised - and not so 
>> difficult to understand for a mere mortal…
>> 
>> It naively seems that (what I still consider a confusingly named method) is 
>> quite simple to extend to handle at least medium sized errors just by doing 
>> something like:
>> 
>> ast := [RBParser parseMethod: source onError: [ :msg :pos :parser | |seqNode 
>> errorNode|
>>  
>>  errorNode := RBParseErrorNode
>>  errorMessage: msg value: parser currentToken value 
>> printString at: pos. 
>>  
>>  seqNode := parser sequenceNodeClass new.
>>  parser 
>>  step; 
>>  parseStatements: true into: seqNode.
>>  
>>  seqNode 
>>  addNodeFirst: errorNode;
>>  yourself
>>  
>>  ]] onDNU: #body: do: [ nil “Handle non method source 
>> fragments"].
>> 
>> 
>> NOTE: I did have to add >>#currentToken as a method to RBParser as it 
>> doesn’t expose very much for the onError blocks, which I think it should to 
>> make them a bit more useful.
>> 
>> Tim
>> 
>>> On 7 Sep 2017, at 14:39, Tim Mackinnon  wrote:
>>> 
>>> Thanks Thierry - I’ve been noodling in the background and next I hit the 
>>> question of “comments” - which I found RB does handle… and then as per your 
>>> point - how to skip past an error and try further down (which it seems that 
>>> the scanner might have the info to let me skip simple things). You seem to 
>>> get sucked in more and more when trying to to this properly - which does 
>>> make it sound like a very good internship or GSoc project.
>>> 
>>> I think I may have enough to get something polished enough to release to 
>>> the wider world. I certainly love having better keyboard support when I’m 
>>> coding - as we type a lot (even though we have simple syntax) - and having 
>>> efficient tools takes away the friction.
>>> 
>>> Next on my hit list, it add the same support to the refactoring tools - 
>>> which while sophisticated are so clunky in use when compared to IntelliJ.
>>> 
>>> Tim
>>> 
 On 7 Sep 2017, at 08:02, Thierry Goubier  wrote:
 
 Hi Tim,
 
 2017-09-01 13:39 GMT+02:00 Tim Mackinnon :
> Thanks Thierry - this is proving an interesting problem domain ...
> 
> I too am using #bestNodeFor: although I don't find it always 

Re: [Pharo-users] Spec "bindings"

[Peter Uhnak]

Hi Rob,

I'm making a note to look at your proposals and I will discuss it with Stef 
later.

> 
> he has more and younger braincells than me

But not enough connections between them. The cells just sit there alone and are 
not talking to anyone. :(

Peter

Re: [Pharo-users] Pharo 6.0 Generating Ruby-on-Rails Applications

[H. Hirzel]

Maybe I should note that a Magritte is surely useful for ideas.
But a solution not using the Magritte modeling approach might be
better for the task of actually generating applications for different
systems / language environments.

Magritte is foremost about modelling domain objects to be used
_within_ the image. It is about descriptions (declarative style)
enriching the definitions of domain models.

A DSL following an imperative style (issuing  "build" commands) is
very fine as well.
The DSL code within the methods might be queried and model information
extracted in case of need if it is not explicit.

HH.

On 9/8/17, p...@highoctane.be  wrote:
> Nice. I'll definitely have a look because I need to prototype something
> quite domain heavy and it may help a lot.
>
> Phil
>
> On Fri, Sep 8, 2017 at 5:09 PM, Peter Fisk  wrote:
>
>> Hi Phil,
>>
>> I already have PHP support for CodeIgniter and Laravel.
>>
>> Adding support for Zend Framework might take a day or so to implement.
>>
>> Any framework which supports MVC and AJAX should be fairly easy to
>> integrate
>> (eg Python/Django, NodeJS/Adonis, etc). The main difference amongst the
>> frameworks lies in the database object mappings.
>>
>> The specific language support is handled by streams.
>>
>> There are streams for HTML, CSS, JavaScript, PHP, Ruby, Python and
>> sub-streams for Ruby/Rails, JavaScript/Qooxdoo, and so on.
>>
>> So, the framework is not at all Ruby or Ruby-on-Rails specific.
>>
>> Cheers,
>>
>> -- Peter
>>
>>
>>
>>
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>
>>
>>
>

Re: [Pharo-users] Standalone HTML Model

[H. Hirzel]

Sean,

the question is of course - is it the HTML only model you are
interested in or is it rather a 'web document model' (i.e. something
which is displayed in a browser) thus including HTML and CSS.

--HH.

On 9/9/17, H. Hirzel  wrote:
> On 9/9/17, Sean P. DeNigris  wrote:
>> I'd like to create HTML via a DSL, like Seaside's canvas builder, but
>> without
>> loading a whole web framework. Any ideas?
>>
>
> Hello Sean
>
>
> 1.
> One idea is _not_ to go for a HTML builder DSL but for a document
> model plus a generator.
> The generator is a visitor for the document object model.
>
> There is the Pillar document model and a visitor already in place.
>
> The current challenge  - actually it is not a challenge - but just
> needs some time -  is to extract the Pillar document model (easy) and
> the tests (needs more time)  so that it can be loaded as a stand-alone
> package.
>
> See a long discussion in a thread in August about including Pillar in the
> image.
>
> The same then applies for the HTML generator. That is just a file-out
> from an image which has the full Pillar loaded.
>
> So IMHO it is not so much about inventing a new HTML builder DSL but
> to "mold" exisiting infrastructure into shape.
>
> This has the advantage that you can generate other representations easily.
>
>
> 2.
> Another idea is to look at HttpView2 done 10 years ago and come up
> with a revised version.
> http://wiki.squeak.org/squeak/182
>
> "No Files. No HTML. Just Smalltalk code!"
>
> A builder: http://wiki.squeak.org/squeak/637
> The element hierarchy: http://wiki.squeak.org/squeak/840
>
>
> Discussion
> ---
>
> Comparison of 1 and 2
>
> In 1 you use a document model (DOM) which is independent from the
> representation in HTML code.
>
> Than you have a generator generating the HTML code. The DOM is
> actually quite close to the HTML DOM.
>
> The Pillar DOM is nicely supported in Pharo with the inspector.
>
> Neither 1 nor 2 actually take CSS into account. An issue which is
> important when you generate web pages.
>
> So from the Smalltalk data model point of view (web document modeling)
> you have a Smalltalk object which is then rendered on two output
> streams
>
> - HTML
> - CSS
>
> Things get interesting in particular if you want to generate
> responsive web sites.
> The you need to do more on the CSS side and with generating pictures as
> well.
>
> Regards
> Hannes
>
>>
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>>
>>
>

Re: [Pharo-users] Standalone HTML Model

[H. Hirzel]

On 9/9/17, Sean P. DeNigris  wrote:
> I'd like to create HTML via a DSL, like Seaside's canvas builder, but
> without
> loading a whole web framework. Any ideas?
>

Hello Sean


1.
One idea is _not_ to go for a HTML builder DSL but for a document
model plus a generator.
The generator is a visitor for the document object model.

There is the Pillar document model and a visitor already in place.

The current challenge  - actually it is not a challenge - but just
needs some time -  is to extract the Pillar document model (easy) and
the tests (needs more time)  so that it can be loaded as a stand-alone
package.

See a long discussion in a thread in August about including Pillar in the image.

The same then applies for the HTML generator. That is just a file-out
from an image which has the full Pillar loaded.

So IMHO it is not so much about inventing a new HTML builder DSL but
to "mold" exisiting infrastructure into shape.

This has the advantage that you can generate other representations easily.


2.
Another idea is to look at HttpView2 done 10 years ago and come up
with a revised version.
http://wiki.squeak.org/squeak/182

"No Files. No HTML. Just Smalltalk code!"

A builder: http://wiki.squeak.org/squeak/637
The element hierarchy: http://wiki.squeak.org/squeak/840


Discussion
---

Comparison of 1 and 2

In 1 you use a document model (DOM) which is independent from the
representation in HTML code.

Than you have a generator generating the HTML code. The DOM is
actually quite close to the HTML DOM.

The Pillar DOM is nicely supported in Pharo with the inspector.

Neither 1 nor 2 actually take CSS into account. An issue which is
important when you generate web pages.

So from the Smalltalk data model point of view (web document modeling)
you have a Smalltalk object which is then rendered on two output
streams

- HTML
- CSS

Things get interesting in particular if you want to generate
responsive web sites.
The you need to do more on the CSS side and with generating pictures as well.

Regards
Hannes

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

Re: [Pharo-users] Let's prepare for Google Code-In 2017 with Pharo Consortium

[Stephane Ducasse]

Hi

Excellent initiative.
Now could we have a github account to store the idea of small tasks?

Stef

On Wed, Sep 6, 2017 at 2:46 PM, Jigyasa Grover
 wrote:
> Hello Pharo-ers !
>
> On behalf of the community, I would like to thank each one of you for their
> significant contribution in the recently concluded *Google Summer of Code
> 2017* with *Pharo Consortium*. We aspire to take-off on a long flight after
> this successful stint. In this spirit, I proposed at ESUG 2017 that we take
> part in the upcoming *Google Code-In 2017*.
>
> GCI is a contest to introduce pre-university students (ages 13-17) to open
> source software development. Because Google Code-in is often the first
> experience many students have with open source, the contest is designed to
> make it easy for students to jump right in with /bite-sized tasks/ (3 to 5
> days) having categorised as: Code, Documentation/Training,
> Outreach/Research, Quality Assurance, or User Interface.
>
> Students search for a task from the list created by us that interests them
> and claim it. They have at least three days to complete it. The student
> works on the task, getting guidance from mentors, if needed. Once the
> student is ready, they submit their work for review through the contest
> website. Mentors from the organisation evaluate the work, provide feedback,
> and if it's complete, accept it so that student can claim a new task.
> Otherwise, specific feedback is provided, and the student goes back to
> improving it.
>
> Participants who complete at least 1 task get a digital certificate.
> Participants who complete 3 or more tasks receive a t-shirt too. At the end
> of the contest, each organisation chooses five finalists to receive limited
> edition Google Code-in hoodies. Two finalists from each organisation get to
> be the grand prize winners and go on a trip to Google Headquarters in
> California !
>
> The contest runs for about 6-8 weeks in December & January generally. With
> organisation applications beginning in October/November, we need to be well
> prepared for this season’s application with a hope to get selected.
>
> As an open source evangelist and a Pharo developer, I would like to invite
> all the experienced members to be a part of the "GCI with Pharo Consortium"
> Team and mentor students. To get added to the “private repository”  (we need
> to keep prospective students away from the task list before the program
> begins  ) where you can put in your tasks/suggestions kindly EMail me or
> any of the previously added mentor.
>
> Looking forward to an appreciable representation from the Pharo community.
>
> Best regards
> Jigyasa Grover
> Pharo Consortium Org Admin, Google Summer of Code 2017
> grover.jigya...@gmail.com
>
> Link to know more about GCI:  https://codein.withgoogle.com/archive/
> 
> Link to sample tasks:
> https://developers.google.com/open-source/gci/resources/example-tasks
> 
> Link to FAQs:  https://developers.google.com/open-source/gci/faq
> 
> Link to contest rules:
> https://developers.google.com/open-source/gci/resources/contest-rules
> 
> Link to GCI presentation for outreach:
> https://developers.google.com/open-source/gci/resources/downloads/Google-Code-in-2016-slides.pdf
> 
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

Re: [Pharo-users] Pharo 6 FileSystem>>changeDirectory: is missing

[Stephane Ducasse]

Alistair

did I miss some pending PR to be integrated for FS?
I'm getting back to reality after a totally fun and intense ESUG conference.
Stef

On Thu, Sep 7, 2017 at 8:26 AM, Alistair Grant  wrote:
> Hi Andreas,
>
> On Wed, Sep 06, 2017 at 04:53:27PM -0700, Andreas Sunardi wrote:
>> Hi Alistair,
>>
>> I found fogbugz #19717 where this was discussed.
>>
>> https://pharo.fogbugz.com/f/cases/19717/
>> FileSystem-workingDirectory-wrong-after-image-moved-to-a-new-folder
>>
>> The issue seems to be the current working directory is saved in instance
>> variable workingDirectory. When the image is moved to another directory, this
>> workingDirectory becomes incorrect. Instance variable 'store', through its #
>> defaultWorkingDirectory, always gives the right answer (however, this answer 
>> is
>> the image directory, not directory where the command is invoked, which is the
>> issue in #05723 you mentioned).
>>
>> Here's a snippet from fogbugz #19717 original problem on how to reproduce it:
>> QUOTE
>> 1/ open an image. evaluate './pharo-local' asFileReference and keep the
>> inspector.
>> 2/ save and quit
>> 3/ move the image to another directory
>> 4/ open the image
>> 5/ evaluate self fullName on the file reference => it will give a wrong path
>> with a reference to the working directory used at file reference creation.
>> ENDQUOTE
>
> Thanks for finding this!
>
> In #20164 I reintroduced caching the working directory, but update it
> when the session is stopped and started, so the above test produces the
> expected results.  As you can see in the comments for the associated PR,
> caching the value was a significant peformance improvement for at least
> one person.
> https://pharo.fogbugz.com/f/cases/20164/Caching-DiskStore-defaultWorkingDirectory
>
>
>> I don't know if it's still debatable, which './pharo-local' the file 
>> reference
>> should refer to, but I think I agree with fogbugz #19717 that it should stay 
>> as
>> relative path.
>>
>> But this is a separate issue than losing the ability to change working
>> directory, which seems to me an unintentional side-effect in the solution. 
>> I'll
>> see if I can jump onto $05723 to request support for changing working
>> directory.
>>
>> On a side note, is current working directory the same as image directory in
>> Pharo? I wonder why we have these issues if they are separate things. I 
>> haven't
>> dived into this, so I can't say much.
>
> Yes, which was the original driver for #05723.  After it is integrated
> the working directory will be the process working directory.  The image
> directory can of course still be accessed with FileLocator
> imageDirectory.
>
> Cheers,
> Alistair
>
>
>> --
>> Andreas
>>
>> On Wed, Sep 6, 2017 at 12:42 PM, Alistair Grant  
>> wrote:
>>
>> On Wed, Sep 06, 2017 at 10:50:05AM -0700, Andreas Sunardi wrote:
>> > It isn't only #changeDirectory: method that is missing. Method #
>> > workingDirectoryPath: and instance variable workingDirectory are also
>> missing.
>> >
>> > FileSystem >> changeDirectory: aPath
>> >   self workingDirectoryPath: (self resolve: aPath)
>> >
>> > FileSystem >> workingDirectoryPath: aPath
>> >   aPath isAbsolute
>> > ifFalse: [ self error: 'Cannot set the working directory to a
>> relative
>> > path' ].
>> >   workingDirectory := aPath
>> >
>> >
>> > To solve my problem, I implemented those and also fixed #
>> initializeWithStore:
>> > and changed #workingDirectoryPath
>> >
>> > FileSystem >> initializeWithStore: aStore
>> >   store := aStore.
>> >   workingDirectory := store defaultWorkingDirectory
>> >
>> > FileSystem >> workingDirectoryPath
>> >   ^ workingDirectory
>> >
>> >
>> > Those are from Pharo 5. However, this breaks Monticello (when opening
>> > Monticello Browser). A FileSystem instance has instance variable
>> > workingDirectory set to nil. This should be impossible. I set 'self 
>> halt'
>> in #
>> > initializeWithStore:. It doesn't get triggered, which tells me the
>> instance
>> > isn't created by normal way. I don't know what's going on there.
>> >
>> >
>> > To fix it, I changed #workingDirectoryPath to
>> >
>> > FileSystem >> workingDirectoryPath
>> >   workingDirectory ifNil: [
>> > workingDirectory := store defaultWorkingDirectory ].
>> >   ^ workingDirectory
>> >
>> >
>> > That solves my problem, but this is a specific tool. I don't know what
>> other
>> > problems those changes will cause. This #ifNil: guard is not in Pharo 
>> 5,
>> so
>> > that makes me worry. In general, the change in FileSystem gives
>> impression that
>> > the it is intentional. But I haven't found the new Pharo 6.1 way to
>> change
>> > working directory, if there's any.
>>
>> I couldn't find a fogbugz issue relating to this - if anyone 

Re: [Pharo-users] Spec "bindings"

[Stephane Ducasse]

Hi Rob

I discussed with peter and I hope that he has more and younger
braincells than me. I'm *super* busy with lectures
preparation, workshop preparation and business issues. So I would love
to get some time to get concentrated but not before beginning of
October at the minimum.
May be when I am at Prague we can discuss with Peter.

Stef


On Sat, Sep 9, 2017 at 4:43 AM, Rob Rothwell  wrote:
>
>
> On Fri, Sep 8, 2017 at 1:24 AM, Stephane Ducasse 
> wrote:
>>
>> I like the idea about your extension.
>> We should really get it so that we understand it.
>
>
> I published some experiments on smalltalkhub in a project called
> "Spec-Bindings" (owner RobRothwell) that loads into a clean 6.1-64 image.
>
> It just has some LabelModel and TextModel capabilities with a few tests and
> very simple examples.  I've never really used smalltalkhub before, though,
> so please let me know if I didn't get it set up right.
>
> I changed and added methods only at this time, but there ComposableModel
> probably needs an instance variable for the subject/domain model.  I didn't
> want to start a new branch of Spec-Core, though, so I created a Presenter
> subclass to create new UIs with, but the widgets all have a ValueHolder
> already (with different names per widget).
>
>>
>>
>> >> > countLabel initializeSubject: subject countHolder
>> >> >
>>
>> >
>> > You're welcome.  Thank you very much for your time--it's helpful to know
>> > there probably isn't some sophisticated wizardly way to do this that I
>> > am
>> > not even able to see or comprehend!
>>
>> :)
>>
>> >
>> >
>> >>
>> >>
>> >> > Then, instead of adding a LabelModel to a ComposableModel, you could
>> >> > add
>> >> > something like a NumberPresenter and specify the spec you want to use
>> >> > (which
>> >> > would in turn display the desired widget).
>> >> > I didn't go that far yet, and created a NumberLabelModel for my
>> >> > example
>> >> > above. It worked, but seems like the wrong way to go about it.  Or
>> >> > maybe
>> >> > you
>> >> > need both...I'm not sure!
>> >> >
>> >> > I also want to take a look at self-updating complex widgets as well
>> >> > (lists,
>> >> > tables, etc...) so that telling a list presenter it's list means that
>> >> > adding
>> >> > a value to that list could automatically update the widget and so on.
>> >> > I had some crude prototyping success with that in VW before deciding
>> >> > (hopefully for the last time) that "native" widgets aren't as
>> >> > important
>> >> > to
>> >> > me as a solid and simple way to connect a model to a UI presentation.
>> >>
>> >>
>> >> > This seems much easier to achieve in Pharo, and after years of
>> >> > intermittent
>> >> > attempts I am hopeful that my knowledge level has finally become
>> >> > sufficient
>> >> > to contribute something to this heroic effort.
>> >>
>> >> Superb.
>> >>
>> >> We are discussing with peter (but EsUG is so intense and I should
>> >> finish the lectures for real now that I do not have the braincells)
>> >> about a pragma driven to declare menus because this is a real lack.
>> >
>> >
>> > Good luck!
>> >
>> >>
>> >>
>> >>
>> >> What I suggest is
>> >> - Please please continue your experiment.
>> >> - It would be great if we can compare some typical examples.
>> >> - After that we can take a decision and improve/modify Spec
>> >> and update the documentation.
>> >
>> >
>> > That's a really good idea since I am no Spec expert!  I can probably
>> > make a
>> > few things work the way I'd like them to, though, in order to produce
>> > some
>> > typical examples like master-detail lists and so on.
>>
>> Yes excellent.
>>
>>
>> >
>> >>
>> >> I want to write a small interface for a small app.
>> >> I checked my code
>> >> and I thought that it was strange that we cannot initialize presenter
>> >> once the model is done
>> >
>> >
>> > Right...you can see in Spec that each type of widget creates a static
>> > ValueHolder ( such as '' asValueHolder ) for each type of widget and
>> > does
>> > not currently offer a method to swap it out with a new one.
>>
>> yes this is not really good.
>
>
> Hopefully my examples show that it shouldn't be too hard to modify this.
>
>>
>>
>>
>> >
>> > Also, there are probably more available Morphic widgets that could be
>> > adapted (like a progress bar as an number presenter, for example).
>> >
>> >>
>> >>
>> >> GameListModel new
>> >>on: GameCollector smallCollection;
>> >>openWithSpec
>> >>
>> >>
>> >> "protocol: #initialization"
>> >>
>> >> initializeWidgets
>> >>   listModel := self newList.
>> >>   listModel items: (collector collectionNamed: #owned)
>> >>
>> >> and then back then I realized that I was wrong.
>>
>> To fit Spec (but Spec is certainly too limited)
>
>
> Like you said, it just needs some continuous improvement!
>
>>
>>
>> >
>> >
>> > It would be interesting to hear the arguments against lists and trees
>> > updating themselves when their underlying objects 

Re: [Pharo-users] Standalone HTML Model

[Stephane Ducasse]

Hi sean

I want the same :). Now I have to finish my lectures for within two
weeks and I should not read this mailing-list :)

I do not remember what we did in Pillar.
Now if you extract the canvas/builder from Seaside and rename it to
avoid conflict I'm all ears.

Stef

On Sat, Sep 9, 2017 at 12:15 AM, Sean P. DeNigris  wrote:
> I'd like to create HTML via a DSL, like Seaside's canvas builder, but without
> loading a whole web framework. Any ideas?
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>

Re: [Pharo-users] STON: Skip Inst Var

[Sven Van Caekenberghe]

> On 9 Sep 2017, at 05:44, Sean P. DeNigris  wrote:
> 
> I was migrating some data from Pharo 4 to Pharo 6.1 and fell over the fact
> that FileSystem has a #workingDirectory instVar in the source, but not in
> the target. I ended up monkey patching STON until the objects were loaded
> and then reverting, but is there a way to skip an inst var via the proper
> STON API?

STON does not work like NeoJSON where you can define your own mapping. For 
STON, there is one, system-wide way to serialize/deserialize a specific class. 
You would have to change the way the offending object get handled.


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

Re: [Pharo-users] #parseMethod:onError: isn't as obvious as expected - is it me?

[Marcus Denker]

there is #parseFaultyMethod:, too. We use RBParser for syntax highlighting.

We do already have “senders” and “implementors working in the AST when using 
Suggestions.

See SugsMenuBuilder>>#findBestNodeFor: 

in the case of non-accepted code, it uses the compiler chain with 
#optionParseErrors (which uses parseFaultyMethod: to parse).

context hasUnacceptedEdits
ifTrue: [ 
root := Smalltalk compiler
source: context code;
options: #(+ optionParseErrors);
parse.
context selectedClass ifNotNil: [ :theClass | root 
methodNode methodClass: theClass ].
root doSemanticAnalysis ]

This works well but fails when you actually are in an error node.. for the same 
code the “dumb” way we use
with standard “senders of” just takes line, looks for spaces and feeds that 
word into the “senders of”..

So to make this work better we need to combine both approaches and deal better 
with the Error Node content.
(e.g. trying to fix it and re-parse or just use the dumb “get the work under 
the cursor” way as a first step).

Marcus

> On 8 Sep 2017, at 03:43, Tim Mackinnon  wrote:
> 
> Damn you smalltalk… you suck me in to little side problems….
> 
> RBParser is actually a lot more flexible than I had realised - and not so 
> difficult to understand for a mere mortal…
> 
> It naively seems that (what I still consider a confusingly named method) is 
> quite simple to extend to handle at least medium sized errors just by doing 
> something like:
> 
> ast := [RBParser parseMethod: source onError: [ :msg :pos :parser | |seqNode 
> errorNode|
>   
>   errorNode := RBParseErrorNode
>   errorMessage: msg value: parser currentToken value 
> printString at: pos. 
>   
>   seqNode := parser sequenceNodeClass new.
>   parser 
>   step; 
>   parseStatements: true into: seqNode.
>   
>   seqNode 
>   addNodeFirst: errorNode;
>   yourself
>   
>   ]] onDNU: #body: do: [ nil “Handle non method source 
> fragments"].
> 
> 
> NOTE: I did have to add >>#currentToken as a method to RBParser as it doesn’t 
> expose very much for the onError blocks, which I think it should to make them 
> a bit more useful.
> 
> Tim
> 
>> On 7 Sep 2017, at 14:39, Tim Mackinnon > > wrote:
>> 
>> Thanks Thierry - I’ve been noodling in the background and next I hit the 
>> question of “comments” - which I found RB does handle… and then as per your 
>> point - how to skip past an error and try further down (which it seems that 
>> the scanner might have the info to let me skip simple things). You seem to 
>> get sucked in more and more when trying to to this properly - which does 
>> make it sound like a very good internship or GSoc project.
>> 
>> I think I may have enough to get something polished enough to release to the 
>> wider world. I certainly love having better keyboard support when I’m coding 
>> - as we type a lot (even though we have simple syntax) - and having 
>> efficient tools takes away the friction.
>> 
>> Next on my hit list, it add the same support to the refactoring tools - 
>> which while sophisticated are so clunky in use when compared to IntelliJ.
>> 
>> Tim
>> 
>>> On 7 Sep 2017, at 08:02, Thierry Goubier >> > wrote:
>>> 
>>> Hi Tim,
>>> 
>>> 2017-09-01 13:39 GMT+02:00 Tim Mackinnon >> >:
>>> Thanks Thierry - this is proving an interesting problem domain ...
>>> 
>>> I too am using #bestNodeFor: although I don't find it always gives the best 
>>> node (it does if you are clearly in the target range, but if you are on the 
>>> outer boundary like the next position after a selector or next to a "." or 
>>> ";" it favours the parent and not the closest node. So in usage I find I 
>>> need to tweak it a bit.
>>> 
>>> Yes, when you are on a boundary, then finding the right node may be 
>>> difficult. When developping the ancestor to smart suggestion, I considered 
>>> #bestNodeFor: as good enough, but I considered looking into "up" and "down" 
>>> ast navigation at a time, and I wasn't alone (I think it was active in the 
>>> Pharo editor at a point).
>>>  
>>> 
>>> I'll look at smacc though - also there is that experimental setting to 
>>> allow parse errors, I don't know if it helps in any way.
>>> 
>>> There is a general question there, which is how you try to parse as much as 
>>> possible while jumping over the error, making the error area as small as 
>>> possible (that would be really great for syntax highlighting, by the way).
>>> 
>>> The problem 

Re: [Pharo-users] Standalone HTML Model

[Sven Van Caekenberghe]

There is ZnHtmlOutputStream, not really a DSL, but it might help.

> On 9 Sep 2017, at 00:15, Sean P. DeNigris  wrote:
> 
> I'd like to create HTML via a DSL, like Seaside's canvas builder, but without
> loading a whole web framework. Any ideas?
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>