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

Re: [Pharo-dev] review request

by Nicolai Hess

2015-01-18 18:35 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > On Sun, Jan 18, 2015 at 7:44 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Hi Ben, >> >> First off, thank you for looking into this, it is important, but it is >> also delicate and few people dare look at this stuff. >> > > This is why it would be good to give it plenty of time to settle in before > Pharo 4 release. > > >> >> I did the scenario you described in #40450 on Mac OS X and everything >> went as you described: although there were tons of notification messages, >> the UI remained usable though slow. I did some Zn tests afterwards, >> including save/restart of the image and did not see any problems. >> >> Sven >> >> > Thanks for testing. > cheers -ben > What about this notifications 'WorldState>>interCyclePause failed.' They happen quite often in some situations, for example open Nautilus and search for a class name in the class search dialog. This inform always pops up if the wait time is small: [(Delay forMilliseconds: 5) waitOtherwise:[1 inform:'otherwise']] fork

Feb. 5, 2015

Re: [Pharo-dev] Howto create a new configuration?

by Nicolai Hess

2015-02-05 23:06 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com>: > I have downloaded the latest Pharo 4 and it looks like Esteban Lorenzano > did the job. There is a new 2.7 version. > No, the version 2.7 is not new, I have some changes that came after that version. > > Cheers, > Juraj > > 5. 2. 2015 v 18:28, Nicolai Hess <nicolaihess(a)web.de>: > > 2015-02-05 21:56 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com>: > >> I am just guessing: try to click on âdevelopmentâ item on the left side. >> > > > -> "Information: Nothing to save" > > Already tried :) > > >> >> Cheers, >> Juraj >> >> > 5. 2. 2015 v 17:13, Nicolai Hess <nicolaihess(a)web.de>: >> > >> > 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] Howto create a new configuration?

by Juraj Kubelka

I have downloaded the latest Pharo 4 and it looks like Esteban Lorenzano did the job. There is a new 2.7 version. Cheers, Juraj > 5. 2. 2015 v 18:28, Nicolai Hess <nicolaihess(a)web.de>: > > 2015-02-05 21:56 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com <mailto:juraj.kubelka@gmail.com>>: > I am just guessing: try to click on âdevelopmentâ item on the left side. > > > -> "Information: Nothing to save" > > Already tried :) > > > Cheers, > Juraj > > > 5. 2. 2015 v 17:13, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>>: > > > > 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] [Slots] Invisible Slots

by Eliot Miranda

On Thu, Feb 5, 2015 at 12:51 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > 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 :-). > +1. This is a great test case for Slots. Having automatically inst vars in a dictionary is interesting it could > allow to have more inst vars than the maximum limit. > or, as in AI frame languages, avoid representing and initializing infrequently-used inst vars > > 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 >> > -- best, Eliot

Feb. 5, 2015

Re: [Pharo-dev] ||

by Eliot Miranda

Hi Thierry, On Thu, Feb 5, 2015 at 1:20 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-02-05 21:28 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> >> 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. >> > > I don't contest the possibilities, it's just that they add a significant > layer of complexity when non mastered (how many Pharo developpers know > which event you have to register to to receive all new methods > notifications? Is that documented in one of the books?), and that, except > for using them as <primitives> or for extensibility, I see other syntaxes > and smalltalk code which are simpler. > > A good example is that the pragma syntax is never included in the one page > Smalltalk syntax description :) > Yes, but that's because of historical accident and the difficulty of keeping docs up to date. Perhaps Pharo By Example can fix this? > (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. >> > > I agree with the "metadata", but I'd prefer a executable, evaluate that > block as a medata literal than the pragma. Something that says > "onceAndStoreAsMetadata", to a block, for example. An API to compiled > methods which says add metadata. > A block is far more difficult to deal with than a pragma. A pragma has a simple key, its selector, and simple access to its arameters, the arguments. A block is opaque. Essentially it can only be executable. Pragmas are both executable and function as annotations. > I strongly agree with your keep it in sync argument, still. Pragmas are > better than nothing. > >> >> >> 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. >> > > Just a naming convention does just that perfectly fine, and with less > lines (except for extensions by external packages) and faster code in many > cases. > Yes, but there end up being lots of naming conventions and they are non-obvious. Whereas pragmas, because they are in-your-face in the methods in question, don't need conventions. They just need documenting ;-). 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 ;-). >> > > Ok, I start to see where the abstraction wasn't working so well... since > pragmas are not executed, when writing a method you can't know if the > pragma is correct, because even executing the method may not trigger the > pragma induced code. So you need the legalPragmas to give metadata on > metadata for the compiler to do a bit of static checking, but it doesn't > work for system-wide pragmas unless you extend Object :( > That's not necessarily true. Some pragmas do cause processing at compile time. For example, an FFI signature pragma can be checked at compile-time. But it's in keeping with smalltalk that type checking is not performed at compile time in most cases, isn't it? Why should one require that pragmas be semantically checked at compile time when normal SMalltalk code isn't? At least one knows that the message instance the pragma is compiled to is a valid object and *can* be performed. So pone does know at least that the pragma is executable. Obviously whether that ability to be executed only becomes potent with the right receiver. So any compiled pragma as the potential to be usefully evaluated. And often it doesn't matter if the pragma reference a completely non > existent method or api, since it is probably never executed by anybody (and > if it is, it won't probably reify the error message properly as a > compilation error as it should, because it may be triggered miles away from > the system browser). > Right. 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 >> > > Yes, and I can point out some of its shortcomings: it's non-obvious, it's > limited, tools, even that many years later don't support them well (in > Squeak or Pharo, at least), its redundant in quite a few variants. > There is lots about Smalltalk that is non-obvious, about programming in general that is non-obvious. I don't see that as a specific criticism of pragmas. Once one knows the idiom it is easy to use; its wide-spread use is evidence of that. And hopefully this conversation will help make it more obvious :-). That it is limited is also not perhaps a useful criticism. The issue is whether it is adequate. I think it is. A literal message goes a long way. I'e not heard of complaints about limitations so far. Do you have specific examples where pragmas are inadequate? The tools /do/ support them. One can do senders and implementors in the browser and see the methods that include them, and the implementors of pragmas. browseAllSelect: will narrow down the search. There is an API for programmatic use (pragmasDo: et al). > > Please, could we improve a bit? Methods belonging to multiple protocols > would give us the same decoupling as pragmas, and I would be free to avoid > them where I shouldn't have to use them :) > Don't appeal to me :-). That's another discussion entirely. I like using protocols but many think that that's really extra-linguistic. Many Smalltalks don't even support categories, and some deployment regimes for Squeak/Pharo strip them out. 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. >> > > That would certainly be interesting :) > > >> >> >>> >>> 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. >> > > Yes! > > Thanks for taking the time to argument, > you're most welcome, and the same to you! -- best, Eliot

Feb. 5, 2015

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

by Sven Van Caekenberghe

> On 05 Feb 2015, at 22:05, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > 2015-02-05 16:18 GMT-03:00 Max Leske <maxleske(a)gmail.com>: >> 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). > > Exactly. > > Plus the references are also independent of the requested transport > protocol (HTTP or HTTPS), so if the request starts on HTTP and no > automatic redirection to HTTPS is applied, all links continue to work, > as well as if the first request happens with HTTPS. > > Regards! Yes, makes sense. Now in Zn #bleedingEdge === Name: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.46 Author: SvenVanCaekenberghe Time: 5 February 2015, 10:32:09.544628 pm UUID: 7364336d-5e0f-485b-9c2e-242c33d7a24d Ancestors: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.45 Extend ZnUrl>>#withRelativeReference: to handle network relative references (thanks Peter Kenny & Max Leske for convincing me that this is needed) === Name: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.32 Author: SvenVanCaekenberghe Time: 5 February 2015, 10:32:28.130956 pm UUID: 28846eea-cd9a-4a27-b54f-d9a1ac171fbd Ancestors: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.31 Extend ZnUrl>>#withRelativeReference: to handle network relative references (thanks Peter Kenny & Max Leske for convincing me that this is needed) === Sven

Feb. 5, 2015

Re: [Pharo-dev] Howto create a new configuration?

by Nicolai Hess

2015-02-05 21:56 GMT+01:00 Juraj Kubelka <juraj.kubelka(a)gmail.com>: > I am just guessing: try to click on âdevelopmentâ item on the left side. > -> "Information: Nothing to save" Already tried :) > > Cheers, > Juraj > > > 5. 2. 2015 v 17:13, Nicolai Hess <nicolaihess(a)web.de>: > > > > 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] ||

by Thierry Goubier

2015-02-05 21:28 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > 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. > I don't contest the possibilities, it's just that they add a significant layer of complexity when non mastered (how many Pharo developpers know which event you have to register to to receive all new methods notifications? Is that documented in one of the books?), and that, except for using them as <primitives> or for extensibility, I see other syntaxes and smalltalk code which are simpler. A good example is that the pragma syntax is never included in the one page Smalltalk syntax description :) > > >> >> >>> (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. > I agree with the "metadata", but I'd prefer a executable, evaluate that block as a medata literal than the pragma. Something that says "onceAndStoreAsMetadata", to a block, for example. An API to compiled methods which says add metadata. I strongly agree with your keep it in sync argument, still. Pragmas are better than nothing. > > > 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. > Just a naming convention does just that perfectly fine, and with less lines (except for extensions by external packages) and faster code in many cases. > > 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 ;-). > Ok, I start to see where the abstraction wasn't working so well... since pragmas are not executed, when writing a method you can't know if the pragma is correct, because even executing the method may not trigger the pragma induced code. So you need the legalPragmas to give metadata on metadata for the compiler to do a bit of static checking, but it doesn't work for system-wide pragmas unless you extend Object :( And often it doesn't matter if the pragma reference a completely non existent method or api, since it is probably never executed by anybody (and if it is, it won't probably reify the error message properly as a compilation error as it should, because it may be triggered miles away from the system browser). > 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 > Yes, and I can point out some of its shortcomings: it's non-obvious, it's limited, tools, even that many years later don't support them well (in Squeak or Pharo, at least), its redundant in quite a few variants. Please, could we improve a bit? Methods belonging to multiple protocols would give us the same decoupling as pragmas, and I would be free to avoid them where I shouldn't have to use them :) > > > 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. > That would certainly be interesting :) > > >> >> 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. > Yes! Thanks for taking the time to argument, Thierry > > > -- > best, > Eliot >

Feb. 5, 2015

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

by Esteban A. Maringolo

2015-02-05 16:18 GMT-03:00 Max Leske <maxleske(a)gmail.com>: > 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). Exactly. Plus the references are also independent of the requested transport protocol (HTTP or HTTPS), so if the request starts on HTTP and no automatic redirection to HTTPS is applied, all links continue to work, as well as if the first request happens with HTTPS. Regards!

Feb. 5, 2015

Re: [Pharo-dev] Howto create a new configuration?

by Juraj Kubelka

I am just guessing: try to click on âdevelopmentâ item on the left side. Cheers, Juraj > 5. 2. 2015 v 17:13, Nicolai Hess <nicolaihess(a)web.de>: > > 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