June 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Xtreams: Debugging Grammars

by Sean P. DeNigris

Sean P. DeNigris wrote > How am I supposed to debug that to find the typo in my giant string > above?! Two problems I found copy/pasting grammars from standard docs: - Repititions (*) were prefix instead of postfix - "\" had to be escaped to "\\" I still wonder about debugging techniques, though. If one was building a grammar from scratch, it might be easy to start with blocks that are constantly working, but the grammar in RFC 5322 is very interwoven. It's hard to see which rules are necessary up front. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Xtreams-Debugging-Grammars-tp4902581p4903438.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 26, 2016

Re: [Pharo-users] Xtreams: Extending Bootstrap

by Sean P. DeNigris

Sean P. DeNigris wrote > - is there any specific reason that rules can't contain dashes? This seems > pretty common. Added by changing #grammrPEG from "Identifier <- [a-zA-Z_] [a-zA-Z0-9_]*" to "Identifier <- [a-zA-Z_] [a-zA-Z0-9_\-]*" Sean P. DeNigris wrote > - Why use <- instead of = to separate the rule name from the definition? > The standards I want to parse use the latter. Added by changing #grammrPEG from "ASSIGN <- "<-"" to "ASSIGN <- "<-" / "="" Both seem to be working well. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Xtreams-Extending-Bootstrap-tp4902579p4903437.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 26, 2016

Re: [Pharo-users] Xtreams: Extending Bootstrap

by Sean P. DeNigris

Sean P. DeNigris wrote > I wanted to extend the Xtream grammar to handle "/d97". Okay, I added to PEGParser class>>grammarPEG ... / BACKSLASH [d] [0-9]+ Sean P. DeNigris wrote > I extended PEGParserGenerator and PEGParserParser with the following: > Escape: backslash character: character hexes: hexes Duh, the above method is just the handler for the rule, akin to PetitParser's ==> block ----- Cheers, Sean -- View this message in context: http://forum.world.st/Xtreams-Extending-Bootstrap-tp4902579p4903436.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 26, 2016

Re: [Pharo-users] Fogbugz 13260 reappears?

by stepharo

we should back port it to 50 I think. Can we tag it as such? Le 26/6/16 Ã 14:55, Alistair Grant a Ã©crit : > Hi Nicolai, > > On Sat, Jun 25, 2016 at 06:54:41PM +0200, Nicolai Hess wrote: >> issue >> 18615 Can not access named temp vector from within optimized block scope >> put a fix (with a new test case for this issue) in the inbox. >> >> >> >> 2016-06-24 23:22 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >> Can you try if this is working with this change (attach .st) >> I'll open an issue and do some more tests. > Thanks again for providing this fix. I want to stick with Pharo 5.0 for > now, would you mind letting me know if the final fix has changed from > the .cs file you sent earlier? > > Cheers, > Alistair > > >

June 26, 2016

Re: [Pharo-users] Fogbugz 13260 reappears?

by Alistair Grant

On Sun, Jun 26, 2016 at 03:49:00PM +0200, Nicolai Hess wrote: > Hi Alistair, > > it is the same fix, I just added a sunit - test. Great, thanks! Cheers, Alistair > 2016-06-26 14:55 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > > Hi Nicolai, > > On Sat, Jun 25, 2016 at 06:54:41PM +0200, Nicolai Hess wrote: > > issue > > 18615 Can not access named temp vector from within optimized block scope > > put a fix (with a new test case for this issue) in the inbox. > > > > > > > > 2016-06-24 23:22 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > >Â Â Â Can you try if this is working with this change (attach .st) > >Â Â Â I'll open an issue and do some more tests. > > Thanks again for providing this fix.Â I want to stick with Pharo 5.0 for > now, would you mind letting me know if the final fix has changed from > the .cs file you sent earlier?

June 26, 2016

Re: [Pharo-users] Fogbugz 13260 reappears?

by Nicolai Hess

Hi Alistair, it is the same fix, I just added a sunit - test. 2016-06-26 14:55 GMT+02:00 Alistair Grant <akgrant0710(a)gmail.com>: > Hi Nicolai, > > On Sat, Jun 25, 2016 at 06:54:41PM +0200, Nicolai Hess wrote: > > issue > > 18615 Can not access named temp vector from within optimized block scope > > put a fix (with a new test case for this issue) in the inbox. > > > > > > > > 2016-06-24 23:22 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > > Can you try if this is working with this change (attach .st) > > I'll open an issue and do some more tests. > > Thanks again for providing this fix. I want to stick with Pharo 5.0 for > now, would you mind letting me know if the final fix has changed from > the .cs file you sent earlier? > > Cheers, > Alistair > > >

June 26, 2016

Re: [Pharo-users] Fogbugz 13260 reappears?

by Alistair Grant

Hi Nicolai, On Sat, Jun 25, 2016 at 06:54:41PM +0200, Nicolai Hess wrote: > issue > 18615 Can not access named temp vector from within optimized block scope > put a fix (with a new test case for this issue) in the inbox. > > > > 2016-06-24 23:22 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > Can you try if this is working with this change (attach .st) > I'll open an issue and do some more tests. Thanks again for providing this fix. I want to stick with Pharo 5.0 for now, would you mind letting me know if the final fix has changed from the .cs file you sent earlier? Cheers, Alistair

June 26, 2016

Re: [Pharo-users] Styling a Pharo UI application

by stepharo

+ 1 Stef > Tommaso, > > can you give some concrete examples of what it is that you wanted to > do to refine your application and that was really hard (or impossible) > to do with Spec? > > As long as we do not know what is wrong, we cannot fix it. > > As long as we do not know what important things are wrong, we cannot > prioritize. > > -- > Does this mail seem too brief? Sorry for that, I donât mean to be > rude! Please see http://emailcharter.org . > > Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/%7Ejfabry> > PLEIAD and RyCh labs - Computer Science Department (DCC) - > University of Chile > >> On Jun 25, 2016, at 15:54, Tommaso Dal Sasso >> <tommaso.dalsasso(a)gmail.com <mailto:tommaso.dalsasso@gmail.com>> wrote: >> >> The beauty that I am looking for as a developer for has to do with >> the code and the API. I consider important how fast I am able to >> prototype a working example --in this Spec is excellent-- and how >> much I can extend the code to refine my application --in this Spec is >> really hard to use--. >

June 26, 2016

Re: [Pharo-users] Styling a Pharo UI application

by Johan Fabry

Tommaso, can you give some concrete examples of what it is that you wanted to do to refine your application and that was really hard (or impossible) to do with Spec? As long as we do not know what is wrong, we cannot fix it. As long as we do not know what important things are wrong, we cannot prioritize. -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org <http://emailcharter.org/> . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On Jun 25, 2016, at 15:54, Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com> wrote: > > The beauty that I am looking for as a developer for has to do with the code and the API. I consider important how fast I am able to prototype a working example --in this Spec is excellent-- and how much I can extend the code to refine my application --in this Spec is really hard to use--.

June 25, 2016

Re: [Pharo-users] Styling a Pharo UI application

by Dimitris Chloupis

The problem is that coders don't understand beauty and design. Usually they disregard it partly or completely. You need an artist for a good GUI , there is no way around this. An Artist will brake every rule of a coder, like backward compatibility, KISS, don't reinvent the wheel , DRY etc Design wise the API must not impose a specific design and deal mainly with graphical side which why usually OpenGL is used. Design is a very lengthy , hard and painful process if high quality is the goal. Generally there is a ton of DIY involved. It's crucial to appeal to the emotional side of the user, since GUI can play pivotal role to keeping the user excited about the app. On Sat, 25 Jun 2016 at 22:56, Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com> wrote: > Just a couple of thoughts from the last days coding GUI in Pharo: > > I don't think that the Spec vs. Morphic vs. Bric has really to do with > "ugliness". > True, the Glamour team is doing an amazing work with providing an > interface that is more pleasing and friendly, but the point for me is not > how Spec or Morphic look. I don't use a library because its widgets look > cool, I use it because the tools I build with it fit in the system i.e., > they look like the rest of the system and respect its settings (provided > that borders, spacing and alignment of the labels are aligned). How the > system and your application look like, is responsibility of a theme manager. > > The beauty that I am looking for as a developer for has to do with the > code and the API. I consider important how fast I am able to prototype a > working example --in this Spec is excellent-- and how much I can extend the > code to refine my application --in this Spec is really hard to use--. > > These last days I spent a lot of time with Morphic and later with Bric. > What I noticed is that Morphic is *really* powerful, but to define a > minimal working example you have to write a lot of code to take care of the > details. On the other hand, Bric abstracts many of these details, allowing > for a more pleasant looking result in less time. > > I now understand why I hear saying a lot that Morphic got out of hand: you > have so many options that one is not not able anymore to discern the > essential ones from the once-in-a-lifetime settings. Since our main source > of documentation comes from inspecting the code, and iterate over a list of > methods requires a human at least linear time (who knows if we can improve > this), a class like Morph becomes a nightmare. > Tommaso > > > > On 25/06/16 16:45, Peter UhnÃ¡k wrote: > > > > On Sat, Jun 25, 2016 at 2:12 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > >> >> >> On Jun 24, 2016, at 19:00, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> >> [â¦] >> >> I know that we donât have designers to inverted something cool, but what >> GT teem did is they took Google material design guidelines and implemented >> widgets in Pharo, so if I use them it will be pleasant to the userâs eye. >> Otherwise we are saying how cool Pharo is and how good we are, but a random >> Android developer can build nicer interface because they have this sexy >> widgets. >> >> >> Just to understand: are you saying that a better set of underlying >> widgets for Spec would solve the âuglinessâ issue for you? >> > > Then this would not a Spec issue, but Morphic/Bloc one. > > >> >> And yes, in the end for me the big turn off with Spec is the direct >> example with Tommaso. You know that something is wrong, so you want to >> change the size of a font. And then you ask on the mailing list and it >> turns out that itâs not that easy and you have to either hack something, or >> submit patch to Specâ¦ In the end Iâve decided to use plain morphic because >> at least there I can change whatever I want. >> >> >> So, again to understand: you want to be able to change the font size of >> any widget from within the application, ignoring the System preference >> settings? >> > > You should be able to do that even now with #whenBuiltDo: > > But it's true that Spec doesn't really have any API for styling, and if > something is customizable (some colors for some widgets, some other > options), it is quite haphazard, similarly for drag and drop (there was a > brief discussion about this about a month ago, but we don't have a solution) > > >

June 25, 2016