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

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

by ClÃ©ment Bera

I also can't wait to have a slot to automatically add instance variables in the additional method state for CompiledMethod subclasses. This shouldn't be tricky for you any more, should it ? I'm bored of not being able to add instance variables to compiledMethod subclasses :-). Having automatically inst vars in a dictionary is interesting it could allow to have more inst vars than the maximum limit. 2015-02-05 16:51 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > 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

development workflow for GTools (GToolkitCore)

by Nicolai Hess

14850 <https://pharo.fogbugz.com/default.asp?14850> Integrate GTools #development "From this version onwards the development version should be integrated." Is this a good idea? Does the #development version always include *all* the latest changes, because after Andrei opened 14866 <https://pharo.fogbugz.com/default.asp?14866> Integrate GTools (which got integrated in 40475) I uploaded some changes for issue 14608 <https://pharo.fogbugz.com/default.asp?14608> ClassTest>>#testClassRespectsPolymorphismWithTrait failing due to Spotter methods I set the status to "Fix Review needed", but my changes are integrated in 40475 too! I am not satisfied with the way external packages are handled. 1. if there is not one slice/changeset per issue, it is even less likely someone will review the changes. 2. you don't know who works when on a issue. They are solved in a bulk. 3. a new configuration might not only includes bugfixes but new features as well. 4. often we have unbound globals / undeclared references or other test failures. Can we use the build server for those external projects (like GToolkitCore, Athens, TxText), and that if a project makes a new configuration, it uses the same issue validator for loading and testing that configuration? nicolai

Feb. 5, 2015

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

by Max Leske

> On 05 Feb 2015, at 17:46, Ben Coman <btc(a)openInWorld.com> wrote: > > > On Thu, Feb 5, 2015 at 11:12 PM, GitHub <noreply(a)github.com <mailto:noreply@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 <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 <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? I would say so, yes. > > (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. You can recompile on the fly if you really need to use the same image. > > Please advise how you'd like me to proceed. > cheers -ben > > Iâd go ahead and remove the conditionals and the old code. The release of Pharo 4 is planned for April I think, so even if something goes wrong, thereâs still time to fix it. Removing the clutter will also make it easier to review your changes; and it will make writing code for you easier. Pharo 4 is still in development (unless I missed something), and development means unstable environment. People who use Pharo 4 are aware of that. Thatâs my two cents anyway. Keep up the great work! Cheers, Max

Feb. 5, 2015

Re: [Pharo-dev] ||

by Eliot Miranda

On Thu, Feb 5, 2015 at 11:34 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-02-05 18:51 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> >> 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? >> > > Because the "they have simplified and reduced code where ever they have > been used" is wrong. I just have to give you a counter example: > OK, the claim is too strong. But they /have/ simplified code in cases where they're appropriate. And I can cite several examples. > > One of the uses of pragmas is associating methods containing Gui commands > or settings to specific objects. Based on an object inspected or selected, > you search among all its methods the ones containing a specific pragma (and > you order them by a parameter to that pragma, if you want), and you execute > that method to retrieve the objects you want (presentations, menu commands, > shortcuts, you name it, I use it :)). > > The code to do that is exactly as long as the one which, on the same > object, retrieve all methods under a certain protocol (the latter being > faster than the pragma one, to boot). > > Each method is one line longer ("the pragma"). > > Each such method usually has in its name a copy of the pragma > (gtInspectorXXX methods, I'm looking at you), because of course this is far > more user friendly to indicate its purpose in the method name than in only > the pragma. > > (There are two more arguments for the use of pragmas in that context, one > which has a direct counter-example, one which hasn't: ) > > Moreover, the semantic of pragmas is "interesting" to describe, and in > some cases, require a good amount of dark magic about a global object > listening to all methods changes and capturing (and executing) certain > methods in a vague relation about when this is going to happen, or being > triggered on specific system events (main menu rebuilding, anyone?). The > funny thing is to see that pattern visible on a profile when loading > packages (talk of a scalable approach). > But triggering in the background happens for maintaining change sets, notifying other clients too. It's not as if pragmas introduced such triggering; that kind of triggering has been in use for a long time. And being able to reshape the GUI automatically is very useful. > > >> (and yes, I'm biassed) >> > > Then you're the right person to give me counter arguments... > > (Now, I'd look differently at pragmas used for gradual typing and so on... > But even for something like FFI, I'd seriously prefer to have Smalltalk > calls to describe the call and its arguments than a kind of script hidden > inside pragmas, just for the discoverability and because it makes one less > idiom to deal with) > Why? A good use of pragmas is to associate meta data with a particular method. Having calls off to the side always introduces the need for book-keeping to keep those methods off to the side in sync with the methods they're describing. Typically everyone rolls their own. But here we're adding a level of triggering just to keep the metadata methods in sync. There is no such need with pragmas; they are always in sync with the methods they describe because they are embedded in their methods. Instead we can use triggering to do useful things, adding a pane to open inspectors as soon as we define the method that describes the pane, adding or removing a menu entry, etc. This is one idiom that covers a host of other cases. That's why I claim that whenever I've seen it used it has reduced complexity. Some history. Steve Dahl, I developed pragmas at ParcPlace, with Vassili Bykov adding abstractions for accessing them. The first step was to replace some ugly class-side code to set unwind bits in ensure: and ifCurtailed: by a pragma the compiler would recognise and set the bits itself. The first real use was to make the VisualWorks launcher's menus extensible. Before pragmas the launcher's menu was static and had lots of disabled entries for launching tools that were sold separately such as DLLAndCConnect. With pragmas the launcher's menu was defined with the base system's tools and then extended as each tool package was loaded, or cut-back as each tool was unloaded. So that decoupled the launcher from introducing new tools. A nice result. We then started using it for the browser and one could plug-in a single tool without redefining the browser's menu methods, which decoupled each extension. All this was done in the context of the parcel system, where we could rapidly load packages (parcels ~= Fuel). Pragmas allowed us to decouple these tools where they collided in places like menu definition, tool registration. Then Tami Lee, who was managing the COM connection that turned a VW image into a COM server, became the first "user" of pragmas outside of myself and Steve. She used it to replace a lot of class-side methods that defined the signatures of methods that comprised the server. It was a lovely clean-up. One could define the COM signature for a method in the method itself, and the class side lost about three separate methods that defined all that metadata. One could read the server method itself and understand its semantics without having to consult the class-side methods. One didn't have to know that there was metadata hidden on the class side because it was right there in your face. Then Vassili used it for his cool inspector framework, Trippy, which was similar to Glamour in some ways, and was a huge improvement over the old Inspector framework, again resulting in a much more pluggable, decoupled and extensible system. Vassili also added the abstractions for accessing pragmas in methods. Then we added checking so that one could restrict the compiler to accept only legal pragmas for a given class. But if we defined the legal pragmas in a class-side method, say legalPragmas, then this would be exactly the kind of single point for extensions that causes collisions between packages, each of which might want to add its own set of pragmas. The solution... use a pragma to mark a class-side method as defining a set of legal pragmas for a class. One could have more than one method defining a set of legal pragmas; packages wishing to add their own cool pragmas were decoupled. Once the system because recursive, it had to be a good idea ;-). There are other uses; you've seen them. I used them in VMMaker to eliminate metadata that was embedded as sends to methods defined as ^self that Slang had to extract and analyse, and filter-out from generated code. They simplified Slang's code anaylsis, made the simulator more efficient (since there were no longer sends to execute). My point is that in all the cases I've seen, using pragmas has - simplified the code - made it obvious that methods have metadata associated with them - replaced specialized ways of associating metadata with code by the general pragma mechanism and in many of the cases it has - provided a more decoupled system - provided a more dynamic and extensible system I've been meaning to write up the history of pragmas for ages, but Vassili, Steve or I have always been too busy. I think a community paper on their use and history would be worth-while, and might go a long way to reduce antipathies like yours. I will forever be in debt to anyone who wants to volunteer to help me write such a paper. > > Thierry > > (Look. I started using Smalltalk in 1992... and up to your description, I > wasn't aware pragmas were supposed to follow message syntax ;) Thanks for > the explanation, by the way) > They /have/ to follow literal message syntax. t's all the compiler will accept. That's why there needs to be a paper. -- best, Eliot

Feb. 5, 2015

Howto create a new configuration?

by Nicolai Hess

Hello, I fixed some issues for Athens and upload the changes to the repository. Now, I want to use Versionner to create a new configuration. What I tried: Open a fresh image Open the Athens repository and load the new changesets -> There are some merge conflicts. Why? There shouldn't be any conflicts. How do you do this? After merging the changes I open Versionner. I thought I have to make a new Release but the button "Release Version" is disabled. What did I miss? nicolai

Feb. 5, 2015

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

by Sven Van Caekenberghe

> On 05 Feb 2015, at 20:13, Max Leske <maxleske(a)gmail.com> wrote: > > >> 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 > > 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/) > > <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? Max, You understood well ;-) OK, thanks for the concrete example. So these are out there in the wild, I'll add a special case to handle these. Thanks, Sven > 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

Peter, OK, thanks for the concrete example. So these are out there in the wild, I'll add a special case to handle these. Thanks, Sven > On 05 Feb 2015, at 20:03, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > Sven > > I agree the '//' case is weird, I would never use it myself. However, my > requirement is to be able to parse and dissect web pages, particularly > Wikipedia and Wiktionary pages, and they use this construction all the time. > Mostly it occurs in link tags in page headers. I think the reason is that > the individual pages are in, for example, en.wiktionary.org, but shared > resources are in bits.wikimedia.org; hence the 'relative' address is in > effect a complete path (in which case why not put 'http:' in front and make > it an absolute address?). > > The problem arises in parsing with the Blanchard parser because it is > designed as a validator, hence it follows up the links in the page header to > make sure the resources exist. This is of no interest to me, I just want to > get at the body of the page, but I carried on using it because it is very > good at parsing the body. I had considered mutilating the parser by cutting > out all the processing it does on link nodes. However, before that happened > Monty pointed me to XMLHTMLParser and then Soup; these are just parsers, not > validators, so as far as they are concerned the link addresses are just > text. > > As I said, I am pretty sure I shall abandon the Blanchard parser and use one > of the two that Monty identified - probably Soup. Hence I can ignore this > problem from now on. Whether you think '//' worth including is for you to > decide. The only argument I can see is that it was handled by the now > deprecated Url class, so in theory it could be used by someone still using > Pharo 2 or earlier, who would find problems on updating to Pharo 3 or later. > > Hope this helps > > Peter Kenny > > -----Original Message----- > From: Sven Van Caekenberghe [mailto:sven@stfx.eu] > Sent: 05 February 2015 17:28 > To: PBKResearch > Cc: monty; Pharo Development List > Subject: Re: ZnUrl>>#withRelativeReference: > > 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-Zn >> Url >> >> 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] TROSMTileProvider

by Thierry Goubier

2015-02-05 15:47 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Thierry, Onil, > > I rounded up my experiments with a 2nd commit on my experimental branch: > > === > Name: Roassal2-SvenVanCaekenberghe.720 > Author: SvenVanCaekenberghe > Time: 5 February 2015, 3:40:43.211681 pm > UUID: 121ffc22-4a30-4153-bef1-e019a92862bc > Ancestors: Roassal2-SvenVanCaekenberghe.719 > > Experimental branch. Second version. > > Some more changes after discussing with Thierry @ Pharo Days and hours of > experimenting > > Added TROSMTileProvider>>#cachedTileNamed: and #memoryCachedTileNamed: > > Rewrote/simplified TROSMShape>>#getTile: to no longer fork a 'get tile' > process when the tile is cached in memory or on the file system > > Removed all hacks trying to optimize the number of times #signalUpdate was > called - made no difference. > > Tried several logging approaches but that did not reveal anything special. > > The observed slowdown for tiles in the file cache but not the memory cache > is still there, even though loading about 10 tiles takes less than 40 ms > (see #testEmptyMemoryCacheParisLevel7) > === > > > Summary, it should be faster, but it is not. Forking and network > downloading are gone, each of about 10 tiles takes less than 4 ms, the > total observed slowdown is still about 1 to 2 seconds - with no extra > #signalUpdate. > > I don't know why and I don't understand. > > I hope somebody can have a look, I feel that we can/should make this > better still. > Yes, but we don't know yet how :( Thanks Sven for all the work. Thierry > > Sven > > > On 28 Jan 2015, at 16:58, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > Hi Sven, > > > > Thanks for the work. I'll have a try (if I manage to get the time) and > we'll meet tomorrow for sure :) > > > > Thierry > > > > 2015-01-28 14:43 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Hi Thierry, Onil, > > > > First let me iterate what I wrote last week, the OSM stuff in Roassal is > very cool, very well written. Great work. > > > > Since I have some experience with OSM maps, tiles and serving them, I > had a look to see if I could optimise the tile drawing/loading, which is > visibly a bit slow, one would assume because of the loading of the tiles > over the network. > > > > I just committed (based on code that I wrote some time ago): > > > > === > > Name: Roassal2-SvenVanCaekenberghe.719 > > Author: SvenVanCaekenberghe > > Time: 28 January 2015, 2:31:50.462461 pm > > UUID: 0978fb6a-d6d0-4d86-a9ae-1f2f83a0b6a2 > > Ancestors: Roassal2-AlexandreBergel.718 > > > > Experimental branch. > > > > Introduction of TROSMTileProvider to optimize getting OSM tiles, adds > one shared memory cache and a local file system cache, predefines and > reuses 6 http clients spread over different hosts. > > > > Modifies TROSMShape>>#getTile: and adds TROSMShape>>#tileNamed: > > === > > > > The strange thing is though, that I can optimise the loading (as > benchmarked separately), but in most cases (not when they are in the memory > cache, but when they are in the file cache) the drawing still has the same > pauses as before - which I don't understand, at all. But it is a bit hard > to explain. > > > > Anyway, Thierry, I will see you tomorrow and the day thereafter and I > hope I can show you what I mean. > > > > Regards, > > > > Sven > > > > > > > > >

Feb. 5, 2015

Re: [Pharo-dev] ||

by Thierry Goubier

2015-02-05 18:51 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > 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? > Because the "they have simplified and reduced code where ever they have been used" is wrong. I just have to give you a counter example: One of the uses of pragmas is associating methods containing Gui commands or settings to specific objects. Based on an object inspected or selected, you search among all its methods the ones containing a specific pragma (and you order them by a parameter to that pragma, if you want), and you execute that method to retrieve the objects you want (presentations, menu commands, shortcuts, you name it, I use it :)). The code to do that is exactly as long as the one which, on the same object, retrieve all methods under a certain protocol (the latter being faster than the pragma one, to boot). Each method is one line longer ("the pragma"). Each such method usually has in its name a copy of the pragma (gtInspectorXXX methods, I'm looking at you), because of course this is far more user friendly to indicate its purpose in the method name than in only the pragma. (There are two more arguments for the use of pragmas in that context, one which has a direct counter-example, one which hasn't: ) Moreover, the semantic of pragmas is "interesting" to describe, and in some cases, require a good amount of dark magic about a global object listening to all methods changes and capturing (and executing) certain methods in a vague relation about when this is going to happen, or being triggered on specific system events (main menu rebuilding, anyone?). The funny thing is to see that pattern visible on a profile when loading packages (talk of a scalable approach). > (and yes, I'm biassed) > Then you're the right person to give me counter arguments... (Now, I'd look differently at pragmas used for gradual typing and so on... But even for something like FFI, I'd seriously prefer to have Smalltalk calls to describe the call and its arguments than a kind of script hidden inside pragmas, just for the discoverability and because it makes one less idiom to deal with) Thierry (Look. I started using Smalltalk in 1992... and up to your description, I wasn't aware pragmas were supposed to follow message syntax ;) Thanks for the explanation, by the way)

Feb. 5, 2015

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

by Max Leske

Addendum: I suspect that this practice will prevent CORS problems. If a page uses https to get the script for instance and the script calls another url on the same server but with http only, the request will fail (thatâs a known problem with some of the Facebook scripts). > On 05 Feb 2015, at 20:13, Max Leske <maxleske(a)gmail.com> wrote: > > >> On 05 Feb 2015, at 19:24, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@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 <http://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 <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 <mailto:maxleske@gmail.com>> wrote: >>> >>>> >>>> On 05 Feb 2015, at 18:28, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@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 <mailto:peter@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' <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 <mailto:sven@stfx.eu>] >>>>> Sent: 05 February 2015 10:30 >>>>> To: Pharo Development List >>>>> Cc: monty; peter(a)pbkresearch.co.uk <mailto:peter@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 <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