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

Spotter idea - exclusion filter and google search syntax

by Ben Coman

Just a random idea for Spotter, being able to exclude items from the search using a hyphen/minus sign. I don't have a use case right now, but it "feels" right, so maybe one will turn up soon. Its a broadly used paradigm per google search ( https://support.google.com/mail/answer/7190?hl=en) Also, it would be useful to be able to search on multiple terms similar to a regular web search. A slightly contrived use case is that I want to investigate drag handling of morphs. So I guess entities will have the word "drag" and then maybe "handler" or "handle" but in which order? Will it be #dragHandler or #handleDrag or #handleEventDrag or #handlesMouseOverDragging: ? A single search term restricts me to having to guess and manually retry each possible order. Searching on "drag hand" and getting all possible ordering would be real nice. cheers -ben

Feb. 7, 2015

Re: [Pharo-dev] ||

by Ben Coman

On Sun, Feb 8, 2015 at 4:55 AM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > > How can I halt the execution of a specific pragma? Can I write <myPragma > halt>? > > In following this discussion, this thought also occurred to me. It would be nice to be able to break at the point where the pragma is being collected. As well as helping determine if the pragma is working, this would help discoverability of how pragmas work. cheers -ben

Feb. 7, 2015

Re: [Pharo-dev] ||

by Thierry Goubier

2015-02-07 20:48 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > Array literals are not executable. They are literals. They need an > interpreter to add semantics. This is one of the reasons why Spec is > poor. Pragmas are Message instances. They respond to sendTo:/sentTo:. > STON is not executable, it needs an interpreter. > The STON thing was a joke on the tagging use of pragmas :) > > There are other ways to add metadata to methods. Without tagging. >>>> >>> >>> Haven't we discussed that? Putting metadata off to the side introduces >>> a bookkeeping problem. It is a bad idea. >>> >> >> And pragmas only partially address that. >> > > Partially? It completely solves the issue of keeping metadata associated > with a method. > It solve the issue of associating a limited form of metadata (one or two pragmas), with a few drawbacks (see below). > > Imagine that Sista works, that it has dozens of tuning points for a method >> (int, no recurse, vect, is a reduce, openCL, thread-safe, hot point, this >> loop should be enrolled) do you imagine writing all that into the method to >> guide Sista with pragmas? You'll end up in exactly the same situation as >> OpenMP 4, where it is possible to write programs with more #pragma lines >> than C/C++ code. >> > > One doesn't need a line per option. One can use... literal arrays > someImportantMethod <sistaTuningHints: #(threadSafe unroll)> > but for Sista we imagine very few tuning options, perhaps only one, which > is to say to the optimizer optimize this method even if it doesn't show up > as a hot spot. Sista is /not/ going to look like gcc. > Hum, that's sad. I wanted to try a few ideas along the ones I see in the HPC projects I'm on: specialisation, vectorisation, accelerator off-loading :( > > > >> The method with the menu pragma is named "worldMenuCommand" ... >> > > I don't see examples of this in the pharo 4 image I have to hand. What's > the full selector? > Search for menu pragmas with the finder; the first two in Pharo30 are: RecentMessageList>>recentMessageListMenuOn: ScriptLoader30>>menuCommandOn: (I just made the worldMenuCommand up :)) The tag is<worldMenu>, so it is strictly descriptive. > > >> The method with the gtInspector pragma is named >> "gtInspectorPresentation..." >> > > This one is ok. The pragma both says the method is a pane in a glamour > inspector, and says what the order is relative to others. One thing that's > broken is that the finder doesn't find any senders. Another thing is that > the pragma doesn't do anything. If the Glamour inspector added panes to > itself by using sentTo: to evaluate the pragma then when you did > "implementors" you'd find the builder. > Ok. We're starting to get somewhere, with a better idea of what the semantic of pragmas should be. And closer to what I said earlier: make pragmas executed at compile time. > > So those examples are not taking full advantage. In VW they're more > interesting, e.g. > searchForStringInSource > "Spawn a Browser on all methods which contain a specified string." > > <menuItem: #(#MethodsWithPhraseDot #menus 'Methods with &Phrase...') > nameKey: nil > menu: #(#listMenu #browse) > position: 21.03 > > ... > In a way, I like this usage: it's clear, it will be executed. In another way, yuck :( You're doing an OpenMP 4 kind of pragma (writing programs in the pragma syntax), forcing us to program in a pure literal dialect of smalltalk :( > > which says which sub menu it is in (listMenu browse), where it is relative > to other entries (21.03), what its hot key is (P). And > MenuAutomaticGeneraotr implements the pragma (which shows up though the > "implementors" menu on the menu pragma method): > menuItem: label nameKey: key menu: menuIDs position: position "If the > method is to be inserted into our menu, create a MenuItem, otherwise answer > nil." | realLabel | menuIDs first = menuName ifFalse: [^nil]. realLabel := > self decodeLabel: label. ^Array with: ((MenuItem labeled: realLabel) > nameKey: key) with: (menuIDs copyFrom: 2 to: menuIDs size) with: position > > >> Additionally, as I told you before: the pragma semantic isn't in the >> method... It's somewhere else in the system and senders of that pragma >> doesn't get it. >> > > I know that very well. If things are done right, that the finder will > find pragmas via "senders", and if the designer has chosen to implement the > pragma in some processing object, then the link is made. But I disagree > that the semantic is entirely elsewhere in the system. The > /implementation/ is elsewhere in the system. The semantic is in the > pragma, in exactly the same way as a message specifies an operation to be > performed and a method specifies an implementation, because... pragmas are > messages. > But they can (and often are) used in a strictly descriptive way because they do not carry any clear semantic in Smalltalk itself. > > >> Just have a look at OmniBrowser and tell me that you don't understand >> where the menu commands are :) >> > > I don't want to criticise OmniBrowser, but if pragmas are used in the > pattern above those relationships become clear. > You can't write full command objects the way you describe (with a single method and pragmas) because: command objects can inherit, they can have mutiple aspects (menu item, shortcut in window, key in menu, activation conditions). Pragmas are a solution if your commands are simple (lightweight command objects) and pragmas can't inherit if they are complex (nor can they use utility methods or complex processing, since they are literal messages). Thanks for all the explanations, this was enlightening :) I'll probably have a look at how I use pragmas in AltBrowser command objects; now those are: clipboardCommands <textAreaCommand> ^ #(#AltCutTextCommand #AltCopyTextCommand #AltPasteTextCommand #AltSelectAllTextCommand) and, with your suggestions, it would become: clipboardCommands <textAreaCommands: #(#AltCutTextCommand #AltCopyTextCommand #AltPasteTextCommand #AltSelectAllTextCommand)> But I stay as strongly against them as before (probably even more: I didn't understand fully how nasty(*) considering them executable would be). I want a better solution :) Happy to disagree :) Thierry (*) i.e. similar to C pragmas

Feb. 7, 2015

Re: [Pharo-dev] ||

by HernÃ¡n Morales Durand

Hi Eliot, 2015-02-07 14:48 GMT-03:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Hernan, > > On Sat, Feb 7, 2015 at 7:41 AM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> >> 2015-02-07 5:59 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: >> >>> Personally I don't like Pragmas, they have not convinced me so far that >>> they fit the style of Smalltalk syntax. I have to confess though I never >>> liked descriptive elements and languages . >>> >>> >> Me neither. Actually the pragma idea is not wrong per se, it is the tag >> syntax to write them which bothers me. Because the world can be described >> with tags if you start that path. >> > > How exactly is the syntax wrong? > I am not saying syntax is wrong, I just don't like it because: 1) Adds another level of representation inside an already reflective system. 2) It could be done with plain common message sends. 3) Should be (to me) "hidden" from method pane, and displayed by a specific tool inside the system browser. > The <literalMessagePattern> syntax predates pragmas. It was used first > for numeric primitives in Smalltalk-76 or Smalltalk-80. Squeak extended it > with primitive:module:. I and others extended it to include arbitrary > literal message patterns. The syntax of a literal message pattern is the > syntax of a send with no receiver and only literal arguments. > The use of this syntax means > a) no new syntax > b) each pragma is potentially executable > c) methods using specific pragmas can be found using "find senders" > d) the execution side of a pragma can be found using "find implementors" > > So what's wrong with that? How is it wrong to use a common Smalltalk > object, a Message, that is well-supported in the system, for method > metadata? > > I get that pragmas are messages, but they assume an implicit receiver, which actually depends on context. If I understood right with pragmas always receiver = destination? If you change things in the communication model (receiver, sender, message, etc.), by removing or adding elements, you have a loss in the message because it gets harder to reconstruct the message send. Consider <eventRegistration> | eventRegistration | { eventRegistration }. self eventRegistration. which of them "it sounds like" you cannot infer their purpose? To me the first because you need the context MyClass>>methodName and you need to browse the pragma to get its purpose. > >> There are other ways to add metadata to methods. Without tagging. >> > > Haven't we discussed that? Putting metadata off to the side introduces a > bookkeeping problem. It is a bad idea. > Yes, but I still have a lot of doubts about feedback with pragmas (I hope you view them as constructive criticism). Is like pragmas assume there is always a perfect message transaction. How can I halt the execution of a specific pragma? Can I write <myPragma halt>? How do I know if it will get executed? Is <shortcut> a functional pragma? How do I distinguis any pragma from being functional or "documentation"? > > >> And they don't need to be in the method pane itself. >> > > For some kinds of metadata, for metadata with semantics, not just a > documentary function, it is important for the metadata to be obvious. > I think this depends on context. Because your work could be towards low-level machinery details or software reenginering, doesn't mean that we all need to view compiler directives, functional and structural annotations, etc. And if I can write some prediction... When someone invents automatic annotation (like happens now with genomes) and decides it will be cool to have them in the image (because you will gain performance, more reflective capabilitites, etc) methods could explode with pragmas to the point gets to be annoying to browse any method. Then the tool will have to be built by need. > No one has argued for hiding the primitive specification off-to-the-side. > "Need" is a poor criticism here because using turing equivalence lots of > things don't "need" to be the way they are. Instead why not ask what are > the pros and cons? > > Ok, many of us knows the pros. I have been using pragmas for a while. But if we stop discussing then it will never adapt to new ideas. So you may want to share your view of cons too :) > >> It is like having to specify protocol because there is no list pane to >> create them. >> > > I disagree. When the pragma is specifying type information, specifying > that the method is an action on a specific menu, is a pane in an inspector, > and many other uses, it is essential that that information be represented, > and putting it in a one-off bookkeeping system is a bad idea. We're not > talking about simple documentary metadata like author, category etc. > Well, I think documentary metadata is tremendously complex. > We're using pragmas for semantics, semantics of the method that are > outside of its execution semantics, semantics about how the method fits in > the broader system. And putting that in non-obvious places is a bad idea. > > I agree. But obvious could be a place where can be located by a method though not necessarily visible. Cheers, HernÃ¡n > >> >> HernÃ¡n >> >>> >>> About python decorators I disagree that are similar to pragmas. Pragmas >>> are focused on being descriptive , python decorators are descriptive as by >>> product. The main focus of python decorators is to shorten code by >>> introducing syntactic sugar. >>> >> > Kilon, pragmas are not limited to being descriptive. > > >> >>> I agree though this is a very interesting discussion and I dont >>> understand most of the things stated here so I leave an open door and mind >>> for pragmas. Maybe one day I will "get it". >>> >> > That would be nice :) > >> >> >> >> >> >>> >>> On Sat, Feb 7, 2015 at 10:02 AM, Thierry Goubier < >>> thierry.goubier(a)gmail.com> wrote: >>> >>>> >>>> >>>> 2015-02-06 22:00 GMT+01:00 stepharo <stepharo(a)free.fr>: >>>> >>>>> Really interesting discussion. I like pragmas but this is interesting >>>>> to see them challenged. >>>>> >>>> >>>> Thanks. It's a pleasure to discuss that way :) >>>> >>>> >>>>> 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 ;-). >>>>>> >>>>> Thierry I'm skeptical that multiple protocol will save the problem >>>>> because you will rely on coding conventions. >>>>> >>>> >>>> Pragma as well: just explain the conventions behind the gtInspector >>>> pragmas, for example. >>>> >>>> But give me multiple protocols and I'll show you the same conventions >>>> rewritten in less lines (and a slightly more efficient code). >>>> >>>> >>>>> And pragma is a clever tagging. >>>>> >>>> >>>> Then maybe we should remove protocols and replace them with pragmas :) >>>> >>>> Thierry >>>> >>>> >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>> >>> >> > > > -- > best, > Eliot >

Feb. 7, 2015

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

by Eliot Miranda

On Sat, Feb 7, 2015 at 9:35 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 07 Feb 2015, at 18:29, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > On Fri, Feb 6, 2015 at 10:13 PM, stepharo <stepharo(a)free.fr> wrote: > >> I want relationships for certain modeling purposes >> What I like is that we should arrive to get a collection of useful slots >> with optimal implementation instead all of us reinventing the wheel. >> >> I have started to collect the examples in Slots-Examples (in #481). > At the start these are artificial (just testing/showing something), but > slowly we will add useful ones, too. > > I started to implement PropertySlot, this uses hidden slots, > initialisation (to set the empty dictionary of the base slot), virtual slots > (the proper slots), reflectively changing the class both when adding and > removing (to add the base slot and remove it as needed). > > and custom byte code generation to read and write with just #at: and > #at:put on the base slotâ¦ > and remember that the closure bytecodes can access a field without a bounds check 140 10001100 kkkkkkkk jjjjjjjj Push Temp At kkkkkkkk In Temp Vector At: jjjjjjjj 141 10001101 kkkkkkkk jjjjjjjj Store Temp At kkkkkkkk In Temp Vector At: jjjjjjjj 142 10001110 kkkkkkkk jjjjjjjj Pop and Store Temp At kkkkkkkk In Temp Vector At: jjjjjjjj -- best, Eliot

Feb. 7, 2015

Re: [Pharo-dev] ||

by Eliot Miranda

On Sat, Feb 7, 2015 at 10:21 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2015-02-07 18:48 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Hi Hernan, >> >> On Sat, Feb 7, 2015 at 7:41 AM, HernÃ¡n Morales Durand < >> hernan.morales(a)gmail.com> wrote: >> >>> >>> 2015-02-07 5:59 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: >>> >>>> Personally I don't like Pragmas, they have not convinced me so far that >>>> they fit the style of Smalltalk syntax. I have to confess though I never >>>> liked descriptive elements and languages . >>>> >>>> >>> Me neither. Actually the pragma idea is not wrong per se, it is the tag >>> syntax to write them which bothers me. Because the world can be described >>> with tags if you start that path. >>> >> >> How exactly is the syntax wrong? >> The <literalMessagePattern> syntax predates pragmas. It was used first >> for numeric primitives in Smalltalk-76 or Smalltalk-80. Squeak extended it >> with primitive:module:. I and others extended it to include arbitrary >> literal message patterns. The syntax of a literal message pattern is the >> syntax of a send with no receiver and only literal arguments. The use of >> this syntax means >> a) no new syntax >> b) each pragma is potentially executable >> c) methods using specific pragmas can be found using "find senders" >> d) the execution side of a pragma can be found using "find implementors" >> >> So what's wrong with that? How is it wrong to use a common Smalltalk >> object, a Message, that is well-supported in the system, for method >> metadata? >> > > The point was: descriptive and the world could be described by tags :) > Message syntax for pragmas is just a consequence of the original primitive > syntax, nothing else (I.e. natural syntax extension). Given how it is used > and that the "potentially executable" is just that, potential, array > literals would work just as well (and I'm nearly sure that a todays design > for pragmas would give us something like STON content :)) > Array literals are not executable. They are literals. They need an interpreter to add semantics. This is one of the reasons why Spec is poor. Pragmas are Message instances. They respond to sendTo:/sentTo:. STON is not executable, it needs an interpreter. There are other ways to add metadata to methods. Without tagging. >>> >> >> Haven't we discussed that? Putting metadata off to the side introduces a >> bookkeeping problem. It is a bad idea. >> > > And pragmas only partially address that. > Partially? It completely solves the issue of keeping metadata associated with a method. Imagine that Sista works, that it has dozens of tuning points for a method > (int, no recurse, vect, is a reduce, openCL, thread-safe, hot point, this > loop should be enrolled) do you imagine writing all that into the method to > guide Sista with pragmas? You'll end up in exactly the same situation as > OpenMP 4, where it is possible to write programs with more #pragma lines > than C/C++ code. > One doesn't need a line per option. One can use... literal arrays someImportantMethod <sistaTuningHints: #(threadSafe unroll)> but for Sista we imagine very few tuning options, perhaps only one, which is to say to the optimizer optimize this method even if it doesn't show up as a hot spot. Sista is /not/ going to look like gcc. > (And C #pragmas are clearly more powerfull than Smalltalk's, since they > are not required to be at the start of the function only) > Sure. Pragmas associate with methods, not statements. > And they don't need to be in the method pane itself. >>> >> >> For some kinds of metadata, for metadata with semantics, not just a >> documentary function, it is important for the metadata to be obvious. No >> one has argued for hiding the primitive specification off-to-the-side. >> "Need" is a poor criticism here because using turing equivalence lots of >> things don't "need" to be the way they are. Instead why not ask what are >> the pros and cons? >> >> >> >>> It is like having to specify protocol because there is no list pane to >>> create them. >>> >> >> I disagree. When the pragma is specifying type information, specifying >> that the method is an action on a specific menu, is a pane in an inspector, >> and many other uses, it is essential that that information be represented, >> and putting it in a one-off bookkeeping system is a bad idea. We're not >> talking about simple documentary metadata like author, category etc. We're >> using pragmas for semantics, semantics of the method that are outside of >> its execution semantics, semantics about how the method fits in the broader >> system. And putting that in non-obvious places is a bad idea. >> > > Good, you're giving my favorite examples for what pragmas are redundant :) > > The method with the menu pragma is named "worldMenuCommand" ... > I don't see examples of this in the pharo 4 image I have to hand. What's the full selector? > The method with the gtInspector pragma is named > "gtInspectorPresentation..." > This one is ok. The pragma both says the method is a pane in a glamour inspector, and says what the order is relative to others. One thing that's broken is that the finder doesn't find any senders. Another thing is that the pragma doesn't do anything. If the Glamour inspector added panes to itself by using sentTo: to evaluate the pragma then when you did "implementors" you'd find the builder. So those examples are not taking full advantage. In VW they're more interesting, e.g. searchForStringInSource "Spawn a Browser on all methods which contain a specified string." <menuItem: #(#MethodsWithPhraseDot #menus 'Methods with &Phrase...') nameKey: nil menu: #(#listMenu #browse) position: 21.03 > ... which says which sub menu it is in (listMenu browse), where it is relative to other entries (21.03), what its hot key is (P). And MenuAutomaticGeneraotr implements the pragma (which shows up though the "implementors" menu on the menu pragma method): menuItem: label nameKey: key menu: menuIDs position: position "If the method is to be inserted into our menu, create a MenuItem, otherwise answer nil." | realLabel | menuIDs first = menuName ifFalse: [^nil]. realLabel := self decodeLabel: label. ^Array with: ((MenuItem labeled: realLabel) nameKey: key) with: (menuIDs copyFrom: 2 to: menuIDs size) with: position > Additionally, as I told you before: the pragma semantic isn't in the > method... It's somewhere else in the system and senders of that pragma > doesn't get it. > I know that very well. If things are done right, that the finder will find pragmas via "senders", and if the designer has chosen to implement the pragma in some processing object, then the link is made. But I disagree that the semantic is entirely elsewhere in the system. The /implementation/ is elsewhere in the system. The semantic is in the pragma, in exactly the same way as a message specifies an operation to be performed and a method specifies an implementation, because... pragmas are messages. > Just have a look at OmniBrowser and tell me that you don't understand > where the menu commands are :) > I don't want to criticise OmniBrowser, but if pragmas are used in the pattern above those relationships become clear. Thierry > -- best, Eliot

Feb. 7, 2015

Re: [Pharo-dev] Metacello + Filetree

by Dale Henrichs

The best way to resolve configuration errors is to run the validator: (MetacelloToolBox validateConfiguration: <configurationClass>) inspect. The class comment of MetacelloMCVersionValidator has information about the various reason codes and between the two you should be able to figure out how to repair the configuration. Let me know if you need additional help interpreting the validation report. Dale On 2/7/15 11:29 AM, Thierry Goubier wrote: > Hi Sebastian, > > It seems that something is amiss in the configuration. You are using a > baseline in the configuration? Are you using #common, #pharoX.x tags? > I am also a bit lost with some of Metacello errors, and it is usually > just a typo in one of the tags, or trying to use two baselines, etc... > > Thierry > > 2015-02-06 14:40 GMT+01:00 Sebastian Tleye <sebastian.tleye(a)gmail.com > <mailto:sebastian.tleye@gmail.com>>: > > Hi Thierry, > > I still have the same problem, I managed to install and configure > GitFiletree, I can add a remote git repository, load packages from > it, etc. > Also, I created a new stable version with the versioner. If I open > the repository with Monticello I can see the history of the the > packages, not only the last one. > However, It's still throwing the same error, it cannot resolve the > name of the package that it needs. > > (By the way, the development version can be still loaded correctly) > > Any Idea of what can it be? > I am not an expert in Metacello, so maybe is a problem with the > Configuration file (in the baseline I tried both, reference to the > remote git repository and to the local gitfiletree repository) > > > 2015-02-05 13:38 GMT+01:00 Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>>: > > > > 2015-02-05 13:26 GMT+01:00 Sebastian Tleye > <sebastian.tleye(a)gmail.com <mailto:sebastian.tleye@gmail.com>>: > > Ok, great, I'll try GitFileTree, we are using the standard > port. > > > Please ask if you need any help. Criticism on the lack of > documentation and missing features accepted :) > > Thierry > > > Thanks! > > 2015-02-05 12:53 GMT+01:00 Serge Stinckwich > <serge.stinckwich(a)gmail.com > <mailto:serge.stinckwich@gmail.com>>: > > Why not launching a kickstarter thing to have someone > (you !) paid to have a clean integration of git/pharo > with documentation ? I guess people, companies and > associations like ESUG can give money for that. > > > Sent from my iPhone > > On 5 fÃ©vr. 2015, at 12:38, Thierry Goubier > <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>> wrote: > >> >> >> 2015-02-05 11:27 GMT+01:00 Sebastian Tleye >> <sebastian.tleye(a)gmail.com >> <mailto:sebastian.tleye@gmail.com>>: >> >> Thanks Yuriy and Thierry, >> >> I see what I can do, I was using Bitbucket until >> some time ago but now we moved our project to a >> private git server! >> >> >> If you are on a private server, then GitFileTree will >> work (except if the git server is on a non-standard >> port: I will add support for that in the near future). >> >> Look for baselines and branches support to make your >> life (and your configurations) simpler. >> >> As I said during PharoDays: we now have a good chunk >> of the necessary infrastructure and we (the Pharo >> community) can develop additional support if needed. >> Asking (funding) the consortium for that could be a >> real cool way of contributing :) >> >> Thierry >> >> >> 2015-02-05 11:13 GMT+01:00 Thierry Goubier >> <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com>>: >> >> Hi Sebastian, >> >> filetree only gives you access to the latest >> version of your packages, and you can't >> access the history without access to the >> underlying version control system you are using. >> >> This access for Metacello is available in two >> ways: via Metacello github:// and >> bitbucket:// urls and tags or branches (but >> you need to be using either github or >> bitbucket), or via GitFileTree if you are >> using git. >> >> Thierry >> >> 2015-02-05 11:03 GMT+01:00 Sebastian Tleye >> <sebastian.tleye(a)gmail.com >> <mailto:sebastian.tleye@gmail.com>>: >> >> Hi, >> >> I am using a filetree repository for my >> project, also I have created a first >> stable version using the versioner tool. >> Everything was working fine until I >> commited more changes, now when I want to >> install the stable version is throwing an >> error saying that cannot resolve the >> package that it needs, however if I load >> the development version it works perfectly. >> >> To clarify a little, >> >> The development version tries to load >> Phadeo-ImporterExporters-SebastianTleye.12 and >> it works perfectly. The stable version >> tries to load >> Phadeo-ImporterExporters-SebastianTleye.10 and >> it throws an error saying that it cannot >> be resolve. >> >> Any Idea of what is happening? >> I read that filetree and Metacello are >> compatibles so I don't know what's the >> problem >> >> >> Hi sebastian >> >> >> Thanks in advance >> >> SebastiÃ¡n Tleye >> >> >> >> >> >> -- >> SebastiÃ¡n Tleye >> >> > > > > -- > SebastiÃ¡n Tleye > > > > > > -- > SebastiÃ¡n Tleye > >

Feb. 7, 2015

Re: [Pharo-dev] Metacello + Filetree

by Thierry Goubier

Hi Sebastian, It seems that something is amiss in the configuration. You are using a baseline in the configuration? Are you using #common, #pharoX.x tags? I am also a bit lost with some of Metacello errors, and it is usually just a typo in one of the tags, or trying to use two baselines, etc... Thierry 2015-02-06 14:40 GMT+01:00 Sebastian Tleye <sebastian.tleye(a)gmail.com>: > Hi Thierry, > > I still have the same problem, I managed to install and configure > GitFiletree, I can add a remote git repository, load packages from it, etc. > Also, I created a new stable version with the versioner. If I open the > repository with Monticello I can see the history of the the packages, not > only the last one. > However, It's still throwing the same error, it cannot resolve the name of > the package that it needs. > > (By the way, the development version can be still loaded correctly) > > Any Idea of what can it be? > I am not an expert in Metacello, so maybe is a problem with the > Configuration file (in the baseline I tried both, reference to the remote > git repository and to the local gitfiletree repository) > > > 2015-02-05 13:38 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> >> >> 2015-02-05 13:26 GMT+01:00 Sebastian Tleye <sebastian.tleye(a)gmail.com>: >> >>> Ok, great, I'll try GitFileTree, we are using the standard port. >>> >> >> Please ask if you need any help. Criticism on the lack of documentation >> and missing features accepted :) >> >> Thierry >> >> >>> >>> Thanks! >>> >>> 2015-02-05 12:53 GMT+01:00 Serge Stinckwich <serge.stinckwich(a)gmail.com> >>> : >>> >>>> Why not launching a kickstarter thing to have someone (you !) paid to >>>> have a clean integration of git/pharo with documentation ? I guess people, >>>> companies and associations like ESUG can give money for that. >>>> >>>> >>>> Sent from my iPhone >>>> >>>> On 5 fÃ©vr. 2015, at 12:38, Thierry Goubier <thierry.goubier(a)gmail.com> >>>> wrote: >>>> >>>> >>>> >>>> 2015-02-05 11:27 GMT+01:00 Sebastian Tleye <sebastian.tleye(a)gmail.com>: >>>> >>>>> Thanks Yuriy and Thierry, >>>>> >>>>> I see what I can do, I was using Bitbucket until some time ago but now >>>>> we moved our project to a private git server! >>>>> >>>> >>>> If you are on a private server, then GitFileTree will work (except if >>>> the git server is on a non-standard port: I will add support for that in >>>> the near future). >>>> >>>> Look for baselines and branches support to make your life (and your >>>> configurations) simpler. >>>> >>>> As I said during PharoDays: we now have a good chunk of the necessary >>>> infrastructure and we (the Pharo community) can develop additional support >>>> if needed. Asking (funding) the consortium for that could be a real cool >>>> way of contributing :) >>>> >>>> Thierry >>>> >>>> >>>>> >>>>> 2015-02-05 11:13 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com> >>>>> : >>>>> >>>>>> Hi Sebastian, >>>>>> >>>>>> filetree only gives you access to the latest version of your >>>>>> packages, and you can't access the history without access to the underlying >>>>>> version control system you are using. >>>>>> >>>>>> This access for Metacello is available in two ways: via Metacello >>>>>> github:// and bitbucket:// urls and tags or branches (but you need to be >>>>>> using either github or bitbucket), or via GitFileTree if you are using git. >>>>>> >>>>>> Thierry >>>>>> >>>>>> 2015-02-05 11:03 GMT+01:00 Sebastian Tleye <sebastian.tleye(a)gmail.com >>>>>> >: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I am using a filetree repository for my project, also I have created >>>>>>> a first stable version using the versioner tool. >>>>>>> Everything was working fine until I commited more changes, now when >>>>>>> I want to install the stable version is throwing an error saying that >>>>>>> cannot resolve the package that it needs, however if I load the development >>>>>>> version it works perfectly. >>>>>>> >>>>>>> To clarify a little, >>>>>>> >>>>>>> The development version tries to load >>>>>>> Phadeo-ImporterExporters-SebastianTleye.12 and it works perfectly. The >>>>>>> stable version tries to load Phadeo-ImporterExporters-SebastianTleye.10 and >>>>>>> it throws an error saying that it cannot be resolve. >>>>>>> >>>>>>> Any Idea of what is happening? >>>>>>> I read that filetree and Metacello are compatibles so I don't know >>>>>>> what's the problem >>>>>>> >>>>>> >>>>>> Hi sebastian >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks in advance >>>>>>> >>>>>>> SebastiÃ¡n Tleye >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> SebastiÃ¡n Tleye >>>>> >>>> >>>> >>> >>> >>> -- >>> SebastiÃ¡n Tleye >>> >> >> > > > -- > SebastiÃ¡n Tleye >

Feb. 7, 2015

Re: [Pharo-dev] Slides PharoDays...

by Marcus Denker

> On 07 Feb 2015, at 19:27, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Missing graphics :) http://www.slideshare.net/YuriyTymchuk/pharo-days-2015 <http://www.slideshare.net/YuriyTymchuk/pharo-days-2015> > can you send my a pdf version of the slides? So that we archive them with the rest. >> On 07 Feb 2015, at 18:18, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> Hi, >> >> Slides are online: >> >> http://www.slideshare.net/pharoproject/presentations <http://www.slideshare.net/pharoproject/presentations> >> >> (thanks to Santiago for collecting and uploading!) >> >> Videos soonâ¦ need to put titles and cross links to slides. >> >> Marcus >

Feb. 7, 2015

Re: [Pharo-dev] Slides PharoDays...

by Yuriy Tymchuk

Missing graphics :) http://www.slideshare.net/YuriyTymchuk/pharo-days-2015 <http://www.slideshare.net/YuriyTymchuk/pharo-days-2015> > On 07 Feb 2015, at 18:18, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > Slides are online: > > http://www.slideshare.net/pharoproject/presentations <http://www.slideshare.net/pharoproject/presentations> > > (thanks to Santiago for collecting and uploading!) > > Videos soonâ¦ need to put titles and cross links to slides. > > Marcus

Feb. 7, 2015