[Pharo-users] Lecture in Togo at Lome
Hi just a little announce to mention that I'm going to Lome (TOGO) to give one week lecture on Pharo and advanced OOP. Stef
[Pharo-users] XML Viewer and XML syntax highlighting
Hi, do we have some nice(r) XML viewer? GTInspector provides tree extension, however I find it often worse than looking at the raw contents (mainly because the tree view doesn't break lines) So my question is: do we have something better? And second (if we don't have something better): How would one go about implementing custom syntax highlighting? Thanks, Peter
[Pharo-users] GTDebugger create method
Hi, does GTDebugger support creation of new methods? Also not having tooltips on the buttons isn't entirely helpful. Thanks, Peter
Re: [Pharo-users] GTDebugger create method
Hi, Yes it does. There should be an icon with a plus sign when a #doesNotUnderstand happens. It seems there is a bug related to displaying tooltips. Cheers, Andrei On Thu, Sep 17, 2015 at 2:19 PM, Peter Uhnák wrote: > Hi, > > does GTDebugger support creation of new methods? > > Also not having tooltips on the buttons isn't entirely helpful. > > > Thanks, > Peter >
Re: [Pharo-users] GTDebugger create method
Ah, plus... I'm blind. Thanks! Peter On Thu, Sep 17, 2015 at 2:23 PM, Andrei Chis wrote: > Hi, > > Yes it does. There should be an icon with a plus sign when a > #doesNotUnderstand happens. > > It seems there is a bug related to displaying tooltips. > > Cheers, > Andrei > > On Thu, Sep 17, 2015 at 2:19 PM, Peter Uhnák wrote: > >> Hi, >> >> does GTDebugger support creation of new methods? >> >> Also not having tooltips on the buttons isn't entirely helpful. >> >> >> Thanks, >> Peter >> > >
Re: [Pharo-users] Problem loading Zinc
This loads fine:
Gofer it
url: 'http://mc.stfx.eu/ZincHTTPComponents';
package: 'ConfigurationOfZincHTTPComponents';
loadStable.
The following command fails saying it could not resolve
Zinc-WebSocket-Tests-SvenVanCaekenberghe.9
#ConfigurationOfZincHTTPComponents asClass project stableVersion
load: #('Core' 'Zodiac' 'WebSocket' 'SSO').
--
View this message in context:
http://forum.world.st/Problem-loading-Zinc-tp4850673p4850771.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Re: [Pharo-users] Problem loading Zinc
> On 17 Sep 2015, at 15:01, sebast...@flowingconcept.com wrote:
>
> This loads fine:
>
> Gofer it
> url: 'http://mc.stfx.eu/ZincHTTPComponents';
> package: 'ConfigurationOfZincHTTPComponents';
> loadStable.
>
>
> The following command fails saying it could not resolve
> Zinc-WebSocket-Tests-SvenVanCaekenberghe.9
Arg, yes, that version is also from Luc, I changed it 'in place'.
> #ConfigurationOfZincHTTPComponents asClass project stableVersion
> load: #('Core' 'Zodiac' 'WebSocket' 'SSO').
>
>
>
> --
> View this message in context:
> http://forum.world.st/Problem-loading-Zinc-tp4850673p4850771.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
[Pharo-users] String vs Symbol use cases
Are there some best practices regarding using strings and symbols? For example I am processing XML and I might query it via xpath... myDocument xPath: 'entity/@name', or myDocument xPath: #'entity/@name' or myDocument / 'entity' @ 'name' or myDocument / #entity @ #name. So does it make sense to prefer one over the other here? Any opinion/advice appreciated, Peter
Re: [Pharo-users] String vs Symbol use cases
I prefer the last one. Doru On Thu, Sep 17, 2015 at 4:10 PM, Peter Uhnák wrote: > Are there some best practices regarding using strings and symbols? > > For example I am processing XML and I might query it via xpath... > > myDocument xPath: 'entity/@name', > > or > > myDocument xPath: #'entity/@name' > > or > > myDocument / 'entity' @ 'name' > > or > > myDocument / #entity @ #name. > > So does it make sense to prefer one over the other here? > > Any opinion/advice appreciated, > > Peter > -- www.tudorgirba.com "Every thing has its own flow"
[Pharo-users] Pharo for Entreprise?
Hi! Where can I get the pdf? I see something here: https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccessfulBuild/artifact/ But I thought it discusses databases and seaside. Isn’t it the case? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-users] Pharo for Entreprise?
http://files.pharo.org/books/enterprisepharo/ seems the most user friendly top level page > On 17 Sep 2015, at 16:23, Alexandre Bergel wrote: > > Hi! > > Where can I get the pdf? > I see something here: > https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccessfulBuild/artifact/ > > But I thought it discusses databases and seaside. Isn’t it the case? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >
Re: [Pharo-users] String vs Symbol use cases
Ideally, both: > myDocument / 'entity' @ 'name' > > or > > myDocument / #entity @ #name. should work. You are here defining a small api to formulate xpath queries, which is great. However, I am not sure that your api will cover all features offered by xpath. The syntax "myDocument xPath: 'entity/@name’” may also be supported. Alexandre > On Sep 17, 2015, at 11:10 AM, Peter Uhnák wrote: > > Are there some best practices regarding using strings and symbols? > > For example I am processing XML and I might query it via xpath... > > myDocument xPath: 'entity/@name', > > or > > myDocument xPath: #'entity/@name' > > or > > myDocument / 'entity' @ 'name' > > or > > myDocument / #entity @ #name. > > So does it make sense to prefer one over the other here? > > Any opinion/advice appreciated, > > Peter -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-users] String vs Symbol use cases
> > You are here defining a small api to formulate xpath queries, which is > great. Nono, this is XPath library by Hernan (available from Catalog Browser), I'm just using it.
Re: [Pharo-users] String vs Symbol use cases
Ah okay! Alexandre > On Sep 17, 2015, at 2:55 PM, Peter Uhnák wrote: > > You are here defining a small api to formulate xpath queries, which is great. > > Nono, this is XPath library by Hernan (available from Catalog Browser), I'm > just using it. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-users] String vs Symbol use cases
Peter, the XPath lib was rewritten not long ago to provide full XPath 1.0 support + extensions, so feel free to mail me with questions or bugs. The old lib didn't implement the whole spec and would crash or infinite loop on valid input, so I felt a rewrite was needed. > myDocument xPath: #'entity/@name' I think treating Symbols as Strings is a bad idea. On GS, Symbols aren't Strings, and #foo = 'foo' is false, so in the XPath lib itself (which now supports GS), I NEVER use Symbols as Strings. But on Squeak/Pharo, this won't hurt you. if you don't need porting, do what you like. > myDocument / 'entity' @ 'name' This is the "DSL" syntax. There are binary messages for each XPath axis: // for "descendant", //~ for "descendant-or-self", ~ for "self" and more in the "enumerating - axis" category. The XPath compiler actually generates sends of these but with block arguments that don't need parsing (string arguments are treated as NameTests and can have wildcard or type tests like '*', '*:foo', or 'text()'). Because the string args are parsed every time, using xPath: can be faster if you save the compiled XPath (like in an inst/class var: "savedXPath := 'some/path' asXPath") and reuse it (with "aNode xPath: savedXPath"). There's also a global compiled XPath cache that's checked before compiling an expression, so xPath: can still be faster even if you don't bother saving. Remember the xPath: usage gives access to full XPath syntax (not just axis and nametests), including predicates, functions, and variables. XPath is really a different language so mapping it all to a ST DSL is tricky. For example, XPath 1.0 is weakly typed so "1" = 1 = "1.0" but clearly this is false in ST. Be aware of the differences when you go from one to the other.
Re: [Pharo-users] String vs Symbol use cases
> Remember the xPath: usage gives access to full XPath syntax (not just axis > and nametests), including predicates, functions, and variables. XPath is > really a different language so mapping it all to a ST DSL is tricky. For > example, XPath 1.0 is weakly typed so "1" = 1 = "1.0" but clearly this is > false in ST. Be aware of the differences when you go from one to the other. By this I mean XPath has many JavaScript style implicit conversions. for example, if an XPath predicate evaluates to a node set, it's converted to a boolean: true if non-empty, false otherwise. Collections in ST obviously aren't converted automatically to true or false when used with ifTrue:ifFalse:.
Re: [Pharo-users] String vs Symbol use cases
Hernan maintained the old lib. The PharoExtras/XPath lib you get from the catalog or config browsers was rewritten and questions/bugs should be sent to me. Note it is incompatible with Pastell, so you can't have both in the same image. > Sent: Thursday, September 17, 2015 at 4:07 PM > From: "Alexandre Bergel" > To: "Any question about pharo is welcome" > Subject: Re: [Pharo-users] String vs Symbol use cases > > Ah okay! > > Alexandre > > > > On Sep 17, 2015, at 2:55 PM, Peter Uhnák wrote: > > > > You are here defining a small api to formulate xpath queries, which is > > great. > > > > Nono, this is XPath library by Hernan (available from Catalog Browser), I'm > > just using it. > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >
[Pharo-users] XPath (was String vs Symbol use cases)
Hi monty, thanks for your answers. The original question wasn't really aimed at XPath, it was just an example, however you raise some important points which I should keep in mind. Now for the XPath itself, I seem to have run into a bug Imagine xml ~ and an xpath '//node[position()=2]' This should return collection containing nodes "b","a.2","b.2", however in Pharo it returns collection with "a.1" Is this something that can be easily fixed? If not I would prefer to work around it than wait for fix. Thanks, Peter
Re: [Pharo-users] XML Viewer and XML syntax highlighting
What's needed is a highlight/styling widget that works with GT that can also be treated like an ordinary write stream. Then you subclass XMLPrettyPrintingWriterFormatter and override the formatting messages to style the stream differently at certain points (like before a start tag, after a start tag). Then change the GT "Source" pane XMLParser method to use "self writeXMLOn: (XMLWriter on: highlightStream formatter: highlightFormatter)". The one drawback (besides performance) is that XMLWriter formatting support is just before/after tags, comments, and other markup elements. You can't add formatting within a start tag, which would be an issue if you want to style text in attr/xmlns values differently. I could fix this by adding more formatting messages to XMLWriter for before/after string values. Does anyone (Doru?) have more info on the GT aspects?
Re: [Pharo-users] XPath (was String vs Symbol use cases)
I understand the problem and I'm studying possible fixes while reviewing the specs, but I need more time. if you could work around it for now, that would be good. I will update you by mail.
Re: [Pharo-users] XML Viewer and XML syntax highlighting
Indeed, you need a parser and afterwards you can use the same approach as I used for the styling Pillar in Rubric: http://www.humane-assessment.com/blog/writing-pillar-books-with-the-gtinspector/ Cheers, Doru On Fri, Sep 18, 2015 at 12:20 AM, monty wrote: > What's needed is a highlight/styling widget that works with GT that can > also be treated like an ordinary write stream. Then you subclass > XMLPrettyPrintingWriterFormatter and override the formatting messages to > style the stream differently at certain points (like before a start tag, > after a start tag). Then change the GT "Source" pane XMLParser method to > use "self writeXMLOn: (XMLWriter on: highlightStream formatter: > highlightFormatter)". > > The one drawback (besides performance) is that XMLWriter formatting > support is just before/after tags, comments, and other markup elements. You > can't add formatting within a start tag, which would be an issue if you > want to style text in attr/xmlns values differently. I could fix this by > adding more formatting messages to XMLWriter for before/after string values. > > Does anyone (Doru?) have more info on the GT aspects? > > -- www.tudorgirba.com "Every thing has its own flow"
