- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Problem with gitfiletree numeration

by Mariano Martinez Peck

On Wed, Jan 13, 2016 at 11:48 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > > > 2016-01-13 15:44 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> >> On Wed, Jan 13, 2016 at 11:33 AM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> >>> >>> 2016-01-13 14:32 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> : >>> >>>> >>>> On Wed, Jan 13, 2016 at 10:00 AM, Thierry Goubier < >>>> thierry.goubier(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> 2016-01-13 13:56 GMT+01:00 Mariano Martinez Peck < >>>>> marianopeck(a)gmail.com>: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier < >>>>>> thierry.goubier(a)gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> 2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck < >>>>>>> marianopeck(a)gmail.com>: >>>>>>> >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> I wanted to know how you manage this situation. >>>>>>>> I had my already existing project in shub repo. Last version >>>>>>>> was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, >>>>>>>> cloned it, and then with gitfiletree I commit for the first time. >>>>>>>> >>>>>>>> The problem is that the commit I did with GitFileTree received this >>>>>>>> MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. >>>>>>>> But in this case I do care because every in a while I would like to >>>>>>>> move/publish some versions from github to shub. And >>>>>>>> OSSubprocess-MarianoMartinezPeck.1 has 2 problems: >>>>>>>> >>>>>>>> 1) It has an older version number but newer contents >>>>>>>> >>>>>>> >>>>>>> >>>>>>>> 2) It's number is not unique. So if I copy versions created from >>>>>>>> github to shub, they would override those versiones created in shub (like >>>>>>>> the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? >>>>>>>> >>>>>>> >>>>>>>> How do you normally solve this? >>>>>>>> >>>>>>> >>>>>>> The best is to move all the sthub versions on git, like that, >>>>>>> gitfiletree will number newer versions higher and this will work. >>>>>>> >>>>>>> >>>>>> OK, I got it. So you mean to use a Gofer pull/push operation to move >>>>>> all versions from shub to github, right? >>>>>> >>>>> >>>>> Yes! >>>>> \ >>>>> >>>> >>>> OK, I did that. Problem is I had screwed up the first version. Because >>>> now in gitfiletree repo, the OSSubprocess-MarianoMartinezPeck.1 is the >>>> "new one" and not the old from shub. I suspect this could bring problems >>>> for history changes, etc... >>>> >>> >>> >>>> Is there a way I can revert and copy the original >>>> OSSubprocess-MarianoMartinezPeck.1 from shub and override the >>>> OSSubprocess-MarianoMartinezPeck.1 from gitfiletree? >>>> >>> >>> Yes. You can reset in git to a previous commit, I think it is with git >>> --reset . >>> >>> But this is problematic if it was pushed on github. >>> >>> >>>> >>>> Or...at least a way to remove everything and start fresh with the >>>> fecth/push??? >>>> >>> >>> Yes, but, again, problematic if it was pushed to github. >>> >>> Thierry >>> >> >> It was pushed to github :( >> >> > :( But deleting on github, resetting on your own repo, recreating on > github and pushing shouldn't take you very long. > > Thanks! That was easy indeed :) > >> Let me ask... do you think my assumption is correct that it could bother >> me when watching the history via MC browser, or a merge or .. any kind of >> MC operation that would be screw up because of this? >> If this is not the case, then...ok, I can live with that mistake. >> > > No, it shouldn't bother you neither make any operation problematic. > > Thierry > > >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > -- Mariano http://marianopeck.wordpress.com

Jan. 13, 2016

Re: [Pharo-dev] Problem with gitfiletree numeration

by Thierry Goubier

2016-01-13 15:46 GMT+01:00 David Allouche <david(a)allouche.net>: > > On 13 Jan 2016, at 15:33, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > 2016-01-13 14:32 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> On Wed, Jan 13, 2016 at 10:00 AM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> >>> >>> 2016-01-13 13:56 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> : >>> >>>> >>>> >>>> On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier < >>>> thierry.goubier(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> 2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck < >>>>> marianopeck(a)gmail.com>: >>>>> >>>>>> Hi guys, >>>>>> >>>>>> I wanted to know how you manage this situation. >>>>>> I had my already existing project in shub repo. Last version >>>>>> was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, >>>>>> cloned it, and then with gitfiletree I commit for the first time. >>>>>> >>>>>> The problem is that the commit I did with GitFileTree received this >>>>>> MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. >>>>>> But in this case I do care because every in a while I would like to >>>>>> move/publish some versions from github to shub. And >>>>>> OSSubprocess-MarianoMartinezPeck.1 has 2 problems: >>>>>> >>>>>> 1) It has an older version number but newer contents >>>>>> >>>>> >>>>> >>>>>> 2) It's number is not unique. So if I copy versions created from >>>>>> github to shub, they would override those versiones created in shub (like >>>>>> the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? >>>>>> >>>>> >>>>>> How do you normally solve this? >>>>>> >>>>> >>>>> The best is to move all the sthub versions on git, like that, >>>>> gitfiletree will number newer versions higher and this will work. >>>>> >>>>> >>>> OK, I got it. So you mean to use a Gofer pull/push operation to move >>>> all versions from shub to github, right? >>>> >>> >>> Yes! >>> \ >>> >> >> OK, I did that. Problem is I had screwed up the first version. Because >> now in gitfiletree repo, the OSSubprocess-MarianoMartinezPeck.1 is the >> "new one" and not the old from shub. I suspect this could bring problems >> for history changes, etc... >> > > >> Is there a way I can revert and copy the original >> OSSubprocess-MarianoMartinezPeck.1 from shub and override the >> OSSubprocess-MarianoMartinezPeck.1 from gitfiletree? >> > > Yes. You can reset in git to a previous commit, I think it is with git > --reset . > > But this is problematic if it was pushed on github. > > >> >> Or...at least a way to remove everything and start fresh with the >> fecth/push??? >> > > Yes, but, again, problematic if it was pushed to github. > > Thierry > > > > Removing commits from a git branch is only really problematic if there are > outstanding, unmerged branches out there, since it tends to cause false > merge conflicts. > > Locals clones of the public repository WILL complain about a divergence, > but they can be fixed by "git pull --force". That is probably acceptable in > your context, since you appear to be in a "botched history" situation. > > Taking a step back, any distributed version control that uses explicit > revision numbers for ordering is broken by design. Yes, Monticello, I am > looking at you. > > That was one of the design mistakes of GNU Arch, and the reason why all > the DVCS that followed it (bzr, hg, git) identify revisions by UUIDs and > define ordering exclusively by the ancestry graph. Experience has also > shown that using content-based UUIDs like hg and git is preferable, for > performance and integrity, to using arbitrary UUIDs like bzr did. > Good to know. I note the ordering by ancestry graph point; I think this could be significant. > > Disclaimer: I am (not yet) familiar with the Monticello model, so I might > be all wrong. But I am quite knowledgeable about DVCS design in general. > Monticello uses explicit revision numbers for ordering and version identification, has access to the full ancestry (in theory; in practice not[*]), and, rarely, uses arbitrary UUIDs to identify versions. Thierry [*] For the Pharo3 release, the ancestry of all core packages was erased from those packages because it was too large.

Jan. 13, 2016

Re: [Pharo-dev] Problem with gitfiletree numeration

by Thierry Goubier

2016-01-13 15:44 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Wed, Jan 13, 2016 at 11:33 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> >> >> 2016-01-13 14:32 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >>> >>> On Wed, Jan 13, 2016 at 10:00 AM, Thierry Goubier < >>> thierry.goubier(a)gmail.com> wrote: >>> >>>> >>>> >>>> 2016-01-13 13:56 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com >>>> >: >>>> >>>>> >>>>> >>>>> On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier < >>>>> thierry.goubier(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> 2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck < >>>>>> marianopeck(a)gmail.com>: >>>>>> >>>>>>> Hi guys, >>>>>>> >>>>>>> I wanted to know how you manage this situation. >>>>>>> I had my already existing project in shub repo. Last version >>>>>>> was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, >>>>>>> cloned it, and then with gitfiletree I commit for the first time. >>>>>>> >>>>>>> The problem is that the commit I did with GitFileTree received this >>>>>>> MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. >>>>>>> But in this case I do care because every in a while I would like to >>>>>>> move/publish some versions from github to shub. And >>>>>>> OSSubprocess-MarianoMartinezPeck.1 has 2 problems: >>>>>>> >>>>>>> 1) It has an older version number but newer contents >>>>>>> >>>>>> >>>>>> >>>>>>> 2) It's number is not unique. So if I copy versions created from >>>>>>> github to shub, they would override those versiones created in shub (like >>>>>>> the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? >>>>>>> >>>>>> >>>>>>> How do you normally solve this? >>>>>>> >>>>>> >>>>>> The best is to move all the sthub versions on git, like that, >>>>>> gitfiletree will number newer versions higher and this will work. >>>>>> >>>>>> >>>>> OK, I got it. So you mean to use a Gofer pull/push operation to move >>>>> all versions from shub to github, right? >>>>> >>>> >>>> Yes! >>>> \ >>>> >>> >>> OK, I did that. Problem is I had screwed up the first version. Because >>> now in gitfiletree repo, the OSSubprocess-MarianoMartinezPeck.1 is the >>> "new one" and not the old from shub. I suspect this could bring problems >>> for history changes, etc... >>> >> >> >>> Is there a way I can revert and copy the original >>> OSSubprocess-MarianoMartinezPeck.1 from shub and override the >>> OSSubprocess-MarianoMartinezPeck.1 from gitfiletree? >>> >> >> Yes. You can reset in git to a previous commit, I think it is with git >> --reset . >> >> But this is problematic if it was pushed on github. >> >> >>> >>> Or...at least a way to remove everything and start fresh with the >>> fecth/push??? >>> >> >> Yes, but, again, problematic if it was pushed to github. >> >> Thierry >> > > It was pushed to github :( > > :( But deleting on github, resetting on your own repo, recreating on github and pushing shouldn't take you very long. > > Let me ask... do you think my assumption is correct that it could bother > me when watching the history via MC browser, or a merge or .. any kind of > MC operation that would be screw up because of this? > If this is not the case, then...ok, I can live with that mistake. > No, it shouldn't bother you neither make any operation problematic. Thierry > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 13, 2016

Re: [Pharo-dev] Problem with gitfiletree numeration

by David Allouche

> On 13 Jan 2016, at 15:33, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2016-01-13 14:32 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>>: > > On Wed, Jan 13, 2016 at 10:00 AM, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > 2016-01-13 13:56 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>>: > > > On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > 2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>>: > Hi guys, > > I wanted to know how you manage this situation. > I had my already existing project in shub repo. Last version was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, cloned it, and then with gitfiletree I commit for the first time. > > The problem is that the commit I did with GitFileTree received this MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But in this case I do care because every in a while I would like to move/publish some versions from github to shub. And OSSubprocess-MarianoMartinezPeck.1 has 2 problems: > > 1) It has an older version number but newer contents > > 2) It's number is not unique. So if I copy versions created from github to shub, they would override those versiones created in shub (like the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? > > How do you normally solve this? > > The best is to move all the sthub versions on git, like that, gitfiletree will number newer versions higher and this will work. > > > OK, I got it. So you mean to use a Gofer pull/push operation to move all versions from shub to github, right? > > Yes! > \ > > OK, I did that. Problem is I had screwed up the first version. Because now in gitfiletree repo, the OSSubprocess-MarianoMartinezPeck.1 is the "new one" and not the old from shub. I suspect this could bring problems for history changes, etc... > > Is there a way I can revert and copy the original OSSubprocess-MarianoMartinezPeck.1 from shub and override the OSSubprocess-MarianoMartinezPeck.1 from gitfiletree? > > Yes. You can reset in git to a previous commit, I think it is with git --reset . > > But this is problematic if it was pushed on github. > > > Or...at least a way to remove everything and start fresh with the fecth/push??? > > Yes, but, again, problematic if it was pushed to github. > > Thierry Removing commits from a git branch is only really problematic if there are outstanding, unmerged branches out there, since it tends to cause false merge conflicts. Locals clones of the public repository WILL complain about a divergence, but they can be fixed by "git pull --force". That is probably acceptable in your context, since you appear to be in a "botched history" situation. Taking a step back, any distributed version control that uses explicit revision numbers for ordering is broken by design. Yes, Monticello, I am looking at you. That was one of the design mistakes of GNU Arch, and the reason why all the DVCS that followed it (bzr, hg, git) identify revisions by UUIDs and define ordering exclusively by the ancestry graph. Experience has also shown that using content-based UUIDs like hg and git is preferable, for performance and integrity, to using arbitrary UUIDs like bzr did. Disclaimer: I am (not yet) familiar with the Monticello model, so I might be all wrong. But I am quite knowledgeable about DVCS design in general.

Jan. 13, 2016

Re: [Pharo-dev] Problem with gitfiletree numeration

by Mariano Martinez Peck

On Wed, Jan 13, 2016 at 11:33 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > > > 2016-01-13 14:32 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> On Wed, Jan 13, 2016 at 10:00 AM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> >>> >>> 2016-01-13 13:56 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> : >>> >>>> >>>> >>>> On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier < >>>> thierry.goubier(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> 2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck < >>>>> marianopeck(a)gmail.com>: >>>>> >>>>>> Hi guys, >>>>>> >>>>>> I wanted to know how you manage this situation. >>>>>> I had my already existing project in shub repo. Last version >>>>>> was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, >>>>>> cloned it, and then with gitfiletree I commit for the first time. >>>>>> >>>>>> The problem is that the commit I did with GitFileTree received this >>>>>> MC version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. >>>>>> But in this case I do care because every in a while I would like to >>>>>> move/publish some versions from github to shub. And >>>>>> OSSubprocess-MarianoMartinezPeck.1 has 2 problems: >>>>>> >>>>>> 1) It has an older version number but newer contents >>>>>> >>>>> >>>>> >>>>>> 2) It's number is not unique. So if I copy versions created from >>>>>> github to shub, they would override those versiones created in shub (like >>>>>> the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? >>>>>> >>>>> >>>>>> How do you normally solve this? >>>>>> >>>>> >>>>> The best is to move all the sthub versions on git, like that, >>>>> gitfiletree will number newer versions higher and this will work. >>>>> >>>>> >>>> OK, I got it. So you mean to use a Gofer pull/push operation to move >>>> all versions from shub to github, right? >>>> >>> >>> Yes! >>> \ >>> >> >> OK, I did that. Problem is I had screwed up the first version. Because >> now in gitfiletree repo, the OSSubprocess-MarianoMartinezPeck.1 is the >> "new one" and not the old from shub. I suspect this could bring problems >> for history changes, etc... >> > > >> Is there a way I can revert and copy the original >> OSSubprocess-MarianoMartinezPeck.1 from shub and override the >> OSSubprocess-MarianoMartinezPeck.1 from gitfiletree? >> > > Yes. You can reset in git to a previous commit, I think it is with git > --reset . > > But this is problematic if it was pushed on github. > > >> >> Or...at least a way to remove everything and start fresh with the >> fecth/push??? >> > > Yes, but, again, problematic if it was pushed to github. > > Thierry > It was pushed to github :( Let me ask... do you think my assumption is correct that it could bother me when watching the history via MC browser, or a merge or .. any kind of MC operation that would be screw up because of this? If this is not the case, then...ok, I can live with that mistake. -- Mariano http://marianopeck.wordpress.com

Jan. 13, 2016

Re: [Pharo-dev] Problem with gitfiletree numeration

by Thierry Goubier

2016-01-13 14:32 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > On Wed, Jan 13, 2016 at 10:00 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> >> >> 2016-01-13 13:56 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >>> >>> >>> On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier < >>> thierry.goubier(a)gmail.com> wrote: >>> >>>> >>>> >>>> 2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com >>>> >: >>>> >>>>> Hi guys, >>>>> >>>>> I wanted to know how you manage this situation. >>>>> I had my already existing project in shub repo. Last version >>>>> was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, >>>>> cloned it, and then with gitfiletree I commit for the first time. >>>>> >>>>> The problem is that the commit I did with GitFileTree received this MC >>>>> version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But >>>>> in this case I do care because every in a while I would like to >>>>> move/publish some versions from github to shub. And >>>>> OSSubprocess-MarianoMartinezPeck.1 has 2 problems: >>>>> >>>>> 1) It has an older version number but newer contents >>>>> >>>> >>>> >>>>> 2) It's number is not unique. So if I copy versions created from >>>>> github to shub, they would override those versiones created in shub (like >>>>> the very old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? >>>>> >>>> >>>>> How do you normally solve this? >>>>> >>>> >>>> The best is to move all the sthub versions on git, like that, >>>> gitfiletree will number newer versions higher and this will work. >>>> >>>> >>> OK, I got it. So you mean to use a Gofer pull/push operation to move all >>> versions from shub to github, right? >>> >> >> Yes! >> \ >> > > OK, I did that. Problem is I had screwed up the first version. Because now > in gitfiletree repo, the OSSubprocess-MarianoMartinezPeck.1 is the "new > one" and not the old from shub. I suspect this could bring problems for > history changes, etc... > > Is there a way I can revert and copy the original > OSSubprocess-MarianoMartinezPeck.1 from shub and override the > OSSubprocess-MarianoMartinezPeck.1 from gitfiletree? > Yes. You can reset in git to a previous commit, I think it is with git --reset . But this is problematic if it was pushed on github. > > Or...at least a way to remove everything and start fresh with the > fecth/push??? > Yes, but, again, problematic if it was pushed to github. Thierry

Jan. 13, 2016

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

by Esteban Lorenzano

another discussion, for another thread :) > On 13 Jan 2016, at 14:35, Christian Haider <Christian.Haider(a)smalltalked-visuals.com> wrote: > > Namespaces â please. > > Best, Christian > > Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Henrik Nergaard > Gesendet: Mittwoch, 13. Januar 2016 14:24 > An: Pharo Development List <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI > > If the prefix is renamed would it be possible to include a delimiter symbol between whatever prefix name and the object name? (for example underscore). Then one could change the how a class is viewed in a simple manner (see attached example). > > > Best regards, > Henrik > > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org <mailto:pharo-dev-bounces@lists.pharo.org>] On Behalf Of Esteban Lorenzano > Sent: Wednesday, January 13, 2016 11:33 AM > To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> > Subject: Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI > > So, recapitulation: > > I want to introduce: > > 1) package renaming, from FFI-NB to UnifiedFFI > 2) prefix renaming, from FFI to UFFI (I will not change method prefix, they will remain ffi* so this is maybe a problemâ¦) > 3) method renaming, from ffiLibraryName to ffiLibrary (we didnât talk about this, but Iâm introducing it because is better name :P) > > I *think* #2 can be skipped, but #1 and #3 are a must. > > opinions? > > Esteban > >> On 13 Jan 2016, at 11:28, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >>> >>> On 13 Jan 2016, at 03:46, Ben Coman <btc(a)openInWorld.com <mailto:btc@openinworld.com>> wrote: >>> >>> >>>> Le 12/1/16 17:58, Denis Kudriashov a Ã©crit : >>>> >>>> Hi >>>> >>>> UFFI reminds me UFO which can be translated like Unified Foreign Objects. >>>> And objects outside image look really like unidentified flying objects. It's just address, blob of bytes and they fly outside smalltalk world >>>> And it has some relation to Alien name. >>>> But maybe it is too much funny name >>> >>> I guess we are considering... >>> >>> Prefix: UFO (shorter) >>> Package: Unified Foreign Objects (longer) >>> >>> Prefix: UFFI (longer) >>> Package: UnifiedFFI (shorter) >>> >>> I like your thinking, but I have mixed feelings. Name is cool. The >>> shorter prefix may be a benefit (though the "I" doesn't add much). >>> But it implies more semantics as an external "object" than external >>> blobs of memory (for example) for C libraries. >>> I like "Unified" because it brings together parts of several >>> implementations (if I understand correctly) and fixes a point of >>> divergence at the VM level making it harder for limited resources to >>> collaborate there. >>> So in the end I think I prefer Unified. >> >> yes, I suppose you are right. >> but I was not considering changing prefix from FFI to UFFI, just repackaging as UnifiedFFI :P >> >> nowâ¦ probably I will do it (not many changes to adapt and probably better for understanding in the long way). >> >> >>> >>> cheers -ben >>> >>> P.S. As I understand it, NativeBoost performs a bit better than >>> UnifiedFFI, but it hindered cross-architecture compatibility - but >>> UnifiedFFI essentially keeps the NativeBoost syntax - so I wonder if >>> its technically feasible for NativeBoost to become a plug-in backend >>> for UnifiedFFI, that could be used is special circumstances that >>> super-performance is required only on supported platforms? >> >> actually (though I do not test it since a couple of months) it should be more or less compatibleâ¦ it was at the beginning, then I made some changesâ¦ >> what is not compatible anymore is the vm who needs to be changed to use executable memory. >> >> Alsoâ¦ yes, NativeBoost is faster (callouts, not callbacks) because you cannot compete with ASM, but you can compite in activation time and optimised codeâ¦ so who knows, in the future that advantage can not exist anymore. >> >> cheers, >> Esteban >> >> >>> >>> >>> >>>> >>>> 2016-01-12 16:55 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >>>> >>>>> >>>>> Hi, >>>>> >>>>> People has pointed (and they are right) that the name of the new FFI >>>>> front-end is misleading. >>>>> So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for >>>>> short) is a better nameâ¦ and to keep packages prox. to regular FFI I was >>>>> thinking on rename FFI-NB packages to FFI-Unifiedâ¦ but maybe is better just >>>>> to rename them as UFFI or UnifiedFFIâ¦ >>>>> what do you think? >>>>> >>>>> Esteban

Jan. 13, 2016

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

by Esteban Lorenzano

not really, underscores are too âanti-Smalltalkâ. > On 13 Jan 2016, at 14:23, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > > If the prefix is renamed would it be possible to include a delimiter symbol between whatever prefix name and the object name? (for example underscore). Then one could change the how a class is viewed in a simple manner (see attached example). > > > Best regards, > Henrik > > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Esteban Lorenzano > Sent: Wednesday, January 13, 2016 11:33 AM > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI > > So, recapitulation: > > I want to introduce: > > 1) package renaming, from FFI-NB to UnifiedFFI > 2) prefix renaming, from FFI to UFFI (I will not change method prefix, they will remain ffi* so this is maybe a problemâ¦) > 3) method renaming, from ffiLibraryName to ffiLibrary (we didnât talk about this, but Iâm introducing it because is better name :P) > > I *think* #2 can be skipped, but #1 and #3 are a must. > > opinions? > > Esteban > > On 13 Jan 2016, at 11:28, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > > > On 13 Jan 2016, at 03:46, Ben Coman <btc(a)openInWorld.com <mailto:btc@openinworld.com>> wrote: > > > Le 12/1/16 17:58, Denis Kudriashov a Ã©crit : > > Hi > > UFFI reminds me UFO which can be translated like Unified Foreign Objects. > And objects outside image look really like unidentified flying objects. It's just address, blob of bytes and they fly outside smalltalk world > And it has some relation to Alien name. > But maybe it is too much funny name > > I guess we are considering... > > Prefix: UFO (shorter) > Package: Unified Foreign Objects (longer) > > Prefix: UFFI (longer) > Package: UnifiedFFI (shorter) > > I like your thinking, but I have mixed feelings. Name is cool. The > shorter prefix may be a benefit (though the "I" doesn't add much). > But it implies more semantics as an external "object" than external > blobs of memory (for example) for C libraries. > I like "Unified" because it brings together parts of several > implementations (if I understand correctly) and fixes a point of > divergence at the VM level making it harder for limited resources to > collaborate there. > So in the end I think I prefer Unified. > > yes, I suppose you are right. > but I was not considering changing prefix from FFI to UFFI, just repackaging as UnifiedFFI :P > > nowâ¦ probably I will do it (not many changes to adapt and probably better for understanding in the long way). > > > > cheers -ben > > P.S. As I understand it, NativeBoost performs a bit better than > UnifiedFFI, but it hindered cross-architecture compatibility - but > UnifiedFFI essentially keeps the NativeBoost syntax - so I wonder if > its technically feasible for NativeBoost to become a plug-in backend > for UnifiedFFI, that could be used is special circumstances that > super-performance is required only on supported platforms? > > actually (though I do not test it since a couple of months) it should be more or less compatibleâ¦ it was at the beginning, then I made some changesâ¦ > what is not compatible anymore is the vm who needs to be changed to use executable memory. > > Alsoâ¦ yes, NativeBoost is faster (callouts, not callbacks) because you cannot compete with ASM, but you can compite in activation time and optimised codeâ¦ so who knows, in the future that advantage can not exist anymore. > > cheers, > Esteban > > > > > > > > 2016-01-12 16:55 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > > > Hi, > > People has pointed (and they are right) that the name of the new FFI > front-end is misleading. > So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for > short) is a better nameâ¦ and to keep packages prox. to regular FFI I was > thinking on rename FFI-NB packages to FFI-Unifiedâ¦ but maybe is better just > to rename them as UFFI or UnifiedFFIâ¦ > what do you think? > > Esteban > > <example.PNG>

Jan. 13, 2016

Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI

by Christian Haider

Namespaces â please. Best, Christian Von: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Im Auftrag von Henrik Nergaard Gesendet: Mittwoch, 13. Januar 2016 14:24 An: Pharo Development List <pharo-dev(a)lists.pharo.org> Betreff: Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI If the prefix is renamed would it be possible to include a delimiter symbol between whatever prefix name and the object name? (for example underscore). Then one could change the how a class is viewed in a simple manner (see attached example). Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Esteban Lorenzano Sent: Wednesday, January 13, 2016 11:33 AM To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: Re: [Pharo-dev] I will rename FFI-NB to UnifiedFFI So, recapitulation: I want to introduce: 1) package renaming, from FFI-NB to UnifiedFFI 2) prefix renaming, from FFI to UFFI (I will not change method prefix, they will remain ffi* so this is maybe a problemâ¦) 3) method renaming, from ffiLibraryName to ffiLibrary (we didnât talk about this, but Iâm introducing it because is better name :P) I *think* #2 can be skipped, but #1 and #3 are a must. opinions? Esteban On 13 Jan 2016, at 11:28, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> > wrote: On 13 Jan 2016, at 03:46, Ben Coman <btc(a)openInWorld.com <mailto:btc@openinworld.com> > wrote: Le 12/1/16 17:58, Denis Kudriashov a Ã©crit : Hi UFFI reminds me UFO which can be translated like Unified Foreign Objects. And objects outside image look really like unidentified flying objects. It's just address, blob of bytes and they fly outside smalltalk world And it has some relation to Alien name. But maybe it is too much funny name I guess we are considering... Prefix: UFO (shorter) Package: Unified Foreign Objects (longer) Prefix: UFFI (longer) Package: UnifiedFFI (shorter) I like your thinking, but I have mixed feelings. Name is cool. The shorter prefix may be a benefit (though the "I" doesn't add much). But it implies more semantics as an external "object" than external blobs of memory (for example) for C libraries. I like "Unified" because it brings together parts of several implementations (if I understand correctly) and fixes a point of divergence at the VM level making it harder for limited resources to collaborate there. So in the end I think I prefer Unified. yes, I suppose you are right. but I was not considering changing prefix from FFI to UFFI, just repackaging as UnifiedFFI :P nowâ¦ probably I will do it (not many changes to adapt and probably better for understanding in the long way). cheers -ben P.S. As I understand it, NativeBoost performs a bit better than UnifiedFFI, but it hindered cross-architecture compatibility - but UnifiedFFI essentially keeps the NativeBoost syntax - so I wonder if its technically feasible for NativeBoost to become a plug-in backend for UnifiedFFI, that could be used is special circumstances that super-performance is required only on supported platforms? actually (though I do not test it since a couple of months) it should be more or less compatibleâ¦ it was at the beginning, then I made some changesâ¦ what is not compatible anymore is the vm who needs to be changed to use executable memory. Alsoâ¦ yes, NativeBoost is faster (callouts, not callbacks) because you cannot compete with ASM, but you can compite in activation time and optimised codeâ¦ so who knows, in the future that advantage can not exist anymore. cheers, Esteban 2016-01-12 16:55 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> >: Hi, People has pointed (and they are right) that the name of the new FFI front-end is misleading. So yesterday I was talking with Stef and we think UnifiedFFI (or UFFI, for short) is a better nameâ¦ and to keep packages prox. to regular FFI I was thinking on rename FFI-NB packages to FFI-Unifiedâ¦ but maybe is better just to rename them as UFFI or UnifiedFFIâ¦ what do you think? Esteban

Jan. 13, 2016

Re: [Pharo-dev] Problem with gitfiletree numeration

by Mariano Martinez Peck

On Wed, Jan 13, 2016 at 10:00 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > > > 2016-01-13 13:56 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> >> On Wed, Jan 13, 2016 at 9:27 AM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> >>> >>> 2016-01-13 13:12 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> : >>> >>>> Hi guys, >>>> >>>> I wanted to know how you manage this situation. >>>> I had my already existing project in shub repo. Last version >>>> was OSSubprocess-MarianoMartinezPeck.43. I then created a github repo, >>>> cloned it, and then with gitfiletree I commit for the first time. >>>> >>>> The problem is that the commit I did with GitFileTree received this MC >>>> version: OSSubprocess-MarianoMartinezPeck.1. Normally I would not care. But >>>> in this case I do care because every in a while I would like to >>>> move/publish some versions from github to shub. And >>>> OSSubprocess-MarianoMartinezPeck.1 has 2 problems: >>>> >>>> 1) It has an older version number but newer contents >>>> >>> >>> >>>> 2) It's number is not unique. So if I copy versions created from github >>>> to shub, they would override those versiones created in shub (like the very >>>> old OSSubprocess-MarianoMartinezPeck.1 from shub) ?? >>>> >>> >>>> How do you normally solve this? >>>> >>> >>> The best is to move all the sthub versions on git, like that, >>> gitfiletree will number newer versions higher and this will work. >>> >>> >> OK, I got it. So you mean to use a Gofer pull/push operation to move all >> versions from shub to github, right? >> > > Yes! > \ > OK, I did that. Problem is I had screwed up the first version. Because now in gitfiletree repo, the OSSubprocess-MarianoMartinezPeck.1 is the "new one" and not the old from shub. I suspect this could bring problems for history changes, etc... Is there a way I can revert and copy the original OSSubprocess-MarianoMartinezPeck.1 from shub and override the OSSubprocess-MarianoMartinezPeck.1 from gitfiletree? Or...at least a way to remove everything and start fresh with the fecth/push??? mmm > It used to work out of the box in the right order, but I now make sure to > push the versions in the right order when I do that (push starting with the > smallest version number). > > Thierry > > >> >> Thanks! >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > -- Mariano http://marianopeck.wordpress.com

Jan. 13, 2016