February 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ZnUrl>>#withRelativeReference:

by Max Leske

> On 05 Feb 2015, at 19:24, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Max, > > Normal relative references are covered now. > > We are talking about a relative reference that looks like > > //otherhost.com/foo/bar.txt <http://otherhost.com/foo/bar.txt> Thatâs what Iâm talking about. Pinterest for example, requires one to use this script (https://developers.pinterest.com/on_hover_pin_it_buttons/ <https://developers.pinterest.com/on_hover_pin_it_buttons/>): <script type="text/javascript" src="//assets.pinterest.com/js/pinit.js" data-pin-hover="true" ></script> And when you look at that script, it loads another script, again via relative url. Did I misread something? Cheers, Max > > why would you do that and not just > > http://otherhost.com/foo/bar.txt > > ? > > I would like a concrete real-world example. > > Sven > >> On 05 Feb 2015, at 18:32, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>> On 05 Feb 2015, at 18:28, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Peter, >>> >>> Thanks for the feedback. (CC-ing the list) >>> >>>> On 05 Feb 2015, at 18:16, PBKResearch <peter(a)pbkresearch.co.uk> wrote: >>>> >>>> Sven >>>> >>>> Thanks for your efforts. I have tried ZnUrl>>#withRelativeReference: on the >>>> examples I gave in my e-mail of 11 Jan. Unfortunately it gives the same >>>> incorrect result as ZnUrl>>#inContextOf: in the case where the relative >>>> address begins with '//'. Admittedly this is a rather weird case, but RFC >>>> 3986 does acknowledge its existence (see para 4.2) and it is dealt with >>>> correctly by the old Url class>># combine:withRelative: (in fact there is >>>> special coding for this case in HierarchicalUrl>># >>>> privateInitializeFromText:). (I am not sure whether the pseudo-code in RFC >>>> 3986 sec 5 deals correctly with an initial '//'; it is not considered >>>> explicitly, but I could not follow all the ramifications of the case with >>>> initial '/'.) >>> >>> I would like to understand why you need it, it seems very weird to me, it was one of the few cases that I decided not to implement: >>> >>> In ZnUrlTests>>#testReferenceResolution >>> >>> " '//g' -> 'http://g'. " "we do not support relative network path references (4.2)" >>> >>> In the RFC they say (page 26) >>> >>> << >>> A relative reference that begins with two slash characters is termed >>> a network-path reference; such references are rarely used. >> >> ârarelyâ is certainly not right today. Most of the social media / maps / blah services provide their scripts with relative references (to fight cross domain request problems I guess?). >> >>>>> >>> >>> Could you please give a concrete example of how/why this is useful ? >>> >>> Thx, >>> >>> Sven >>> >>>> I feel rather guilty that you have gone to so much trouble because, thanks >>>> to Monty, I now have two alternatives to the Blanchard parser (XMLHTMLParser >>>> and Soup). I shall pretty certainly be using one or other of these in >>>> future, in place of the Blanchard parser, because they provide more flexible >>>> ways of interrogating the resulting DOM - and also because they are actively >>>> maintained. So from my point of view there is now no need for you to pursue >>>> this any further - unless you see this as a loose end to be tidied up. >>> >>> Not problem, I am trying to make it right. >>> >>>> Thanks again >>>> >>>> Peter Kenny >>>> >>>> PS I can't post to the Pharo Development List, so I left that out of the >>>> addressee list. >>>> >>>> -----Original Message----- >>>> From: Sven Van Caekenberghe [mailto:sven@stfx.eu] >>>> Sent: 05 February 2015 10:30 >>>> To: Pharo Development List >>>> Cc: monty; peter(a)pbkresearch.co.uk >>>> Subject: ZnUrl>>#withRelativeReference: >>>> >>>> Hi, >>>> >>>> I added ZnUrl>>#withRelativeReference: which implements the process >>>> described in section 5 of RFC 3986. >>>> >>>> https://pharo.fogbugz.com/f/cases/14855/Add-reference-resolution-to-ZnUrl >>>> >>>> Summary: >>>> >>>> In certain contexts (like links on a webpage) partial URLs are used that >>>> must be interpreted relative to a base URL (like the URL of the webpage >>>> itself). >>>> >>>> Example: >>>> >>>> 'http://www.site.com/static/html/home.html' asZnUrl >>>> withRelativeReference: '../js/menu.js' >>>> >>>> => http://www.site.com/static/js/menu.js >>>> >>>> This was previously not possible with ZnUrl. >>>> >>>> If you know this stuff, please have a look. >>>> >>>> Monty ? Peter ? >>>> >>>> Sven >>>> >>>> PS: this is in #bleedingEdge for now > >

Feb. 5, 2015

Re: [Pharo-dev] ZnUrl>>#withRelativeReference:

by Sven Van Caekenberghe

Max, Normal relative references are covered now. We are talking about a relative reference that looks like //otherhost.com/foo/bar.txt why would you do that and not just http://otherhost.com/foo/bar.txt ? I would like a concrete real-world example. Sven > On 05 Feb 2015, at 18:32, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 05 Feb 2015, at 18:28, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Peter, >> >> Thanks for the feedback. (CC-ing the list) >> >>> On 05 Feb 2015, at 18:16, PBKResearch <peter(a)pbkresearch.co.uk> wrote: >>> >>> Sven >>> >>> Thanks for your efforts. I have tried ZnUrl>>#withRelativeReference: on the >>> examples I gave in my e-mail of 11 Jan. Unfortunately it gives the same >>> incorrect result as ZnUrl>>#inContextOf: in the case where the relative >>> address begins with '//'. Admittedly this is a rather weird case, but RFC >>> 3986 does acknowledge its existence (see para 4.2) and it is dealt with >>> correctly by the old Url class>># combine:withRelative: (in fact there is >>> special coding for this case in HierarchicalUrl>># >>> privateInitializeFromText:). (I am not sure whether the pseudo-code in RFC >>> 3986 sec 5 deals correctly with an initial '//'; it is not considered >>> explicitly, but I could not follow all the ramifications of the case with >>> initial '/'.) >> >> I would like to understand why you need it, it seems very weird to me, it was one of the few cases that I decided not to implement: >> >> In ZnUrlTests>>#testReferenceResolution >> >> " '//g' -> 'http://g'. " "we do not support relative network path references (4.2)" >> >> In the RFC they say (page 26) >> >> << >> A relative reference that begins with two slash characters is termed >> a network-path reference; such references are rarely used. > > ârarelyâ is certainly not right today. Most of the social media / maps / blah services provide their scripts with relative references (to fight cross domain request problems I guess?). > >>>> >> >> Could you please give a concrete example of how/why this is useful ? >> >> Thx, >> >> Sven >> >>> I feel rather guilty that you have gone to so much trouble because, thanks >>> to Monty, I now have two alternatives to the Blanchard parser (XMLHTMLParser >>> and Soup). I shall pretty certainly be using one or other of these in >>> future, in place of the Blanchard parser, because they provide more flexible >>> ways of interrogating the resulting DOM - and also because they are actively >>> maintained. So from my point of view there is now no need for you to pursue >>> this any further - unless you see this as a loose end to be tidied up. >> >> Not problem, I am trying to make it right. >> >>> Thanks again >>> >>> Peter Kenny >>> >>> PS I can't post to the Pharo Development List, so I left that out of the >>> addressee list. >>> >>> -----Original Message----- >>> From: Sven Van Caekenberghe [mailto:sven@stfx.eu] >>> Sent: 05 February 2015 10:30 >>> To: Pharo Development List >>> Cc: monty; peter(a)pbkresearch.co.uk >>> Subject: ZnUrl>>#withRelativeReference: >>> >>> Hi, >>> >>> I added ZnUrl>>#withRelativeReference: which implements the process >>> described in section 5 of RFC 3986. >>> >>> https://pharo.fogbugz.com/f/cases/14855/Add-reference-resolution-to-ZnUrl >>> >>> Summary: >>> >>> In certain contexts (like links on a webpage) partial URLs are used that >>> must be interpreted relative to a base URL (like the URL of the webpage >>> itself). >>> >>> Example: >>> >>> 'http://www.site.com/static/html/home.html' asZnUrl >>> withRelativeReference: '../js/menu.js' >>> >>> => http://www.site.com/static/js/menu.js >>> >>> This was previously not possible with ZnUrl. >>> >>> If you know this stuff, please have a look. >>> >>> Monty ? Peter ? >>> >>> Sven >>> >>> PS: this is in #bleedingEdge for now

Feb. 5, 2015

Re: [Pharo-dev] ||

by Eliot Miranda

On Thu, Feb 5, 2015 at 2:31 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-02-05 10:55 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >> It is obviously a compromise (or a continuum) between abstractions and >> performance. >> > > I agree. With a special view in that we are in a sub domain where simple > things well designed (Smalltalk, that is) are amazingly good at supporting > complex designs. > > >> >> But there should remain a focus on efficiency (not just speed but also >> memory), it is hard to fix these things years later. >> > > And I like the fact that efficient code and design is often a pleasure to > read and learn from :) > > Now, being radical: could we get rid of pragmas ? The only reason I see to > them is that they allow extension by external packages, because we can't > have methods which belong to two protocols (*). > They are a Smalltalk-centric way of adding arbitrary metadata to methods; Smalltalk-centric in that a pragma is a Message instance, may be queried for senders, performed, etc, and that it can be parsed using the standard compiler (they add no new syntax). They have been broadly used. IME they have simplified and reduced code where ever they have been used. They don't have to be there but they're a good thing. Why do you want to get rid of them? (and yes, I'm biassed) > Thierry > > (*) I tried to get rid of them in some of my stuff, where it is used in > the same way GTInspector and GTSpooter uses pragmas, and I had to stop > because of that feature. All other uses of pragmas are replaceable (and > often, as in the gt stuff, redundant). > -- best, Eliot

Feb. 5, 2015

Re: [Pharo-dev] ZnUrl>>#withRelativeReference:

by Max Leske

> On 05 Feb 2015, at 18:28, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Peter, > > Thanks for the feedback. (CC-ing the list) > >> On 05 Feb 2015, at 18:16, PBKResearch <peter(a)pbkresearch.co.uk> wrote: >> >> Sven >> >> Thanks for your efforts. I have tried ZnUrl>>#withRelativeReference: on the >> examples I gave in my e-mail of 11 Jan. Unfortunately it gives the same >> incorrect result as ZnUrl>>#inContextOf: in the case where the relative >> address begins with '//'. Admittedly this is a rather weird case, but RFC >> 3986 does acknowledge its existence (see para 4.2) and it is dealt with >> correctly by the old Url class>># combine:withRelative: (in fact there is >> special coding for this case in HierarchicalUrl>># >> privateInitializeFromText:). (I am not sure whether the pseudo-code in RFC >> 3986 sec 5 deals correctly with an initial '//'; it is not considered >> explicitly, but I could not follow all the ramifications of the case with >> initial '/'.) > > I would like to understand why you need it, it seems very weird to me, it was one of the few cases that I decided not to implement: > > In ZnUrlTests>>#testReferenceResolution > > " '//g' -> 'http://g'. " "we do not support relative network path references (4.2)" > > In the RFC they say (page 26) > > << > A relative reference that begins with two slash characters is termed > a network-path reference; such references are rarely used. ârarelyâ is certainly not right today. Most of the social media / maps / blah services provide their scripts with relative references (to fight cross domain request problems I guess?). >>> > > Could you please give a concrete example of how/why this is useful ? > > Thx, > > Sven > >> I feel rather guilty that you have gone to so much trouble because, thanks >> to Monty, I now have two alternatives to the Blanchard parser (XMLHTMLParser >> and Soup). I shall pretty certainly be using one or other of these in >> future, in place of the Blanchard parser, because they provide more flexible >> ways of interrogating the resulting DOM - and also because they are actively >> maintained. So from my point of view there is now no need for you to pursue >> this any further - unless you see this as a loose end to be tidied up. > > Not problem, I am trying to make it right. > >> Thanks again >> >> Peter Kenny >> >> PS I can't post to the Pharo Development List, so I left that out of the >> addressee list. >> >> -----Original Message----- >> From: Sven Van Caekenberghe [mailto:sven@stfx.eu] >> Sent: 05 February 2015 10:30 >> To: Pharo Development List >> Cc: monty; peter(a)pbkresearch.co.uk >> Subject: ZnUrl>>#withRelativeReference: >> >> Hi, >> >> I added ZnUrl>>#withRelativeReference: which implements the process >> described in section 5 of RFC 3986. >> >> https://pharo.fogbugz.com/f/cases/14855/Add-reference-resolution-to-ZnUrl >> >> Summary: >> >> In certain contexts (like links on a webpage) partial URLs are used that >> must be interpreted relative to a base URL (like the URL of the webpage >> itself). >> >> Example: >> >> 'http://www.site.com/static/html/home.html' asZnUrl >> withRelativeReference: '../js/menu.js' >> >> => http://www.site.com/static/js/menu.js >> >> This was previously not possible with ZnUrl. >> >> If you know this stuff, please have a look. >> >> Monty ? Peter ? >> >> Sven >> >> PS: this is in #bleedingEdge for now >> > >

Feb. 5, 2015

Re: [Pharo-dev] ZnUrl>>#withRelativeReference:

by Sven Van Caekenberghe

Peter, Thanks for the feedback. (CC-ing the list) > On 05 Feb 2015, at 18:16, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > Sven > > Thanks for your efforts. I have tried ZnUrl>>#withRelativeReference: on the > examples I gave in my e-mail of 11 Jan. Unfortunately it gives the same > incorrect result as ZnUrl>>#inContextOf: in the case where the relative > address begins with '//'. Admittedly this is a rather weird case, but RFC > 3986 does acknowledge its existence (see para 4.2) and it is dealt with > correctly by the old Url class>># combine:withRelative: (in fact there is > special coding for this case in HierarchicalUrl>># > privateInitializeFromText:). (I am not sure whether the pseudo-code in RFC > 3986 sec 5 deals correctly with an initial '//'; it is not considered > explicitly, but I could not follow all the ramifications of the case with > initial '/'.) I would like to understand why you need it, it seems very weird to me, it was one of the few cases that I decided not to implement: In ZnUrlTests>>#testReferenceResolution " '//g' -> 'http://g'. " "we do not support relative network path references (4.2)" In the RFC they say (page 26) << A relative reference that begins with two slash characters is termed a network-path reference; such references are rarely used. >> Could you please give a concrete example of how/why this is useful ? Thx, Sven > I feel rather guilty that you have gone to so much trouble because, thanks > to Monty, I now have two alternatives to the Blanchard parser (XMLHTMLParser > and Soup). I shall pretty certainly be using one or other of these in > future, in place of the Blanchard parser, because they provide more flexible > ways of interrogating the resulting DOM - and also because they are actively > maintained. So from my point of view there is now no need for you to pursue > this any further - unless you see this as a loose end to be tidied up. Not problem, I am trying to make it right. > Thanks again > > Peter Kenny > > PS I can't post to the Pharo Development List, so I left that out of the > addressee list. > > -----Original Message----- > From: Sven Van Caekenberghe [mailto:sven@stfx.eu] > Sent: 05 February 2015 10:30 > To: Pharo Development List > Cc: monty; peter(a)pbkresearch.co.uk > Subject: ZnUrl>>#withRelativeReference: > > Hi, > > I added ZnUrl>>#withRelativeReference: which implements the process > described in section 5 of RFC 3986. > > https://pharo.fogbugz.com/f/cases/14855/Add-reference-resolution-to-ZnUrl > > Summary: > > In certain contexts (like links on a webpage) partial URLs are used that > must be interpreted relative to a base URL (like the URL of the webpage > itself). > > Example: > > 'http://www.site.com/static/html/home.html' asZnUrl > withRelativeReference: '../js/menu.js' > > => http://www.site.com/static/js/menu.js > > This was previously not possible with ZnUrl. > > If you know this stuff, please have a look. > > Monty ? Peter ? > > Sven > > PS: this is in #bleedingEdge for now >

Feb. 5, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 6a5096: 40477

by Ben Coman

On Thu, Feb 5, 2015 at 11:12 PM, GitHub <noreply(a)github.com> wrote: > > > Log Message: > ----------- > 40477 > > 14669 Delay refactoring (part 2a) - avoid UI locking up when timer event > loop is stopped > https://pharo.fogbugz.com/f/cases/14669 > > > Thanks Max and Marcus for review and pushing this through. Next step is Issue 14353 "Delay refactoring (Part 2) - change from milliseconds to microseconds" and I started to review rebasing this onto the latest build. Now left over from Part 1 ( https://pharo.fogbugz.com/default.asp?14261) is lots of conditional code wrap of the form... self newCodeEnabled ifTrue: [ "my new code" ] ifFalse: [ "the old code" ] However this conditional code wrap clutters things making it harder to review changes going forward. So I was wondering it was preferable for me to clean that out first, before pushing 14353 for review. For Part 1 it served a few purposes... (1) It was required to make an instantaneous transition to the new architecture. However this no longer required since integration of Issue 14669 now allows the DelayScheduler to be stopped to change code without locking the system. (2) It provided an emergency fallback to disable the new architecture, since this was deep-diving into critical infrastructure. However Part 1 was integrated in November, so is that long enough for the code to have proved itself? (3) It allowed easy switching back and forth for benchmarking. Maybe still useful, but I don't think this is enough on its own to keep the newCodeEnabled conditional code wraps. Benchmarking can still be done on separate build before and after integration of subsequent changes. Please advise how you'd like me to proceed. cheers -ben

Feb. 5, 2015

[pharo-project/pharo-core] 6c62c7: 40478

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 6c62c7435d8edd501c5be5a33f1ef5791f86a515 https://github.com/pharo-project/pharo-core/commit/6c62c7435d8edd501c5be5a3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-02-05 (Thu, 05 Feb 2015) Changed paths: M Kernel.package/ClassDescription.class/instance/slots/slots.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script478.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40478.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot.package/AbstractLayout.class/instance/accessing/visibleSlots.st A Slot.package/HiddenInstanceVariableSlot.class/README.md A Slot.package/HiddenInstanceVariableSlot.class/definition.st A Slot.package/HiddenInstanceVariableSlot.class/instance/testing/isVisible.st Log Message: ----------- 40478 14798 Slots: add HiddenInstanceVariableSlot https://pharo.fogbugz.com/f/cases/14798 http://files.pharo.org/image/40/40478.zip

Feb. 5, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40478 Home: https://github.com/pharo-project/pharo-core

Feb. 5, 2015

Re: [Pharo-dev] [squeak-dev] Re: ||

by Frank Shearar

On 5 February 2015 at 15:35, Levente Uzonyi <leves(a)elte.hu> wrote: > On Thu, 5 Feb 2015, Marcus Denker wrote: > >> >>> On 05 Feb 2015, at 10:04, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> >>>> On 04 Feb 2015, at 22:04, Levente Uzonyi <leves(a)elte.hu> wrote: >>>> >>>> A single parser is a nice goal, but performance is top priority for >>>> Shout, because it should do it's job real-time. When it starts lagging >>>> behind, then people just turn it off, because it doesn't help them. >>>> Can those parsers (SHRBTextStyler and a Smalltalk parser written using >>>> PetitParser) parse an average method in less than 20ms on an average >>>> machine? >>> >>> >>> I have not yet benchmarked itâ¦ PetitParser as it is is too slow, but we >>> will soon have a faster version (factor 10). >>> >>> We should do some benchmarks. For using, it seems ok. With a fast machine >>> + JIT, which does not say much of course. >>> (there is a setting 'AST based coloringâ in Pharo3 and Pharo4, but it is >>> turned off by default). >>> >>> One thing that is nice with the AST is that it can be used for other >>> things, too. e.g. in Pharo we have a menu that is defined >>> by the AST nodes and structural navigation in the editor. >>> > > Rebuilding the whole AST after every keystroke is possible, but keeping it > real-time is a bit challenging. > > I would love to see an editor, which works on the AST directly - aka it maps > the source code to AST nodes, and just updates the smallest possible subtree > at each keystroke. Implementing such editor has it's challenges ofc, like > typing a single character can invalidate the whole code, but the editor > should keep the AST somehow in that case too. C#'s Roslyn does this: http://blogs.msdn.com/b/ericlippert/archive/2012/06/08/persistence-facades-… frank >> Another way to see it: How would the original Smalltalk be designed if >> they would have had 4GB RAM in 1978? >> >> What fascinates me still is that Smalltalk used the existing resources >> (even building their own machines) to an >> extreme, while today we are obsessed to find reasons why we can not do >> anything that makes the system >> slower or use more memory than yesterday. And that even with resources >> growing every yearâ¦ >> >> This is why we e.g. now have a meta object describing every instance >> variable in Pharo. I am sure there are people >> who will see these ~7000 objects as pure wasteâ¦ while I would say that we >> have already *now* the resources to be >> even more radical. > > > I think this is a different thing. Improvements are always welcome, as long > as they don't step on your toes. > > About Slots: I don't see their advantages yet (other than bitfields, but > those are so rare in Smalltalk that I implement them causes no trouble. And > they are just an optimization over using multiple fields.). > > Levente > >> >> Marcus

Feb. 5, 2015

Re: [Pharo-dev] [Slots] Invisible Slots

by Marcus Denker

On Mon, Jan 26, 2015 at 6:03 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Next: Hidden ivar > > > This is now finally in #478. This is for notch just a subclass to have a normal InstanceVariable in a hidden version, later we will use the wrapping machism that we use already for MetaLinks to make it possible to hide any slot. (e.g. BooleanSlot will use a BitFieldSlot that might span multiple ivars). For the first version this simple version should be enough. Marcus

Feb. 5, 2015