- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] binary serialization

by Robert Withers

Good morning, Max. Thank you for the example. I got a little confused, between migrations and substitutions. My issue with no-arg blocks, I believe, is the inability to access my scope object to maintain the object tables. I'm attempting to write my own Materializer, Decoder and Materialization. At the moment, I'm just going to walk the graph, testing and do #becomes:. See how well that works when I get a test. It's really good to know about that other list. thanks so much ^^ Robert On 10/14/2015 04:15 AM, Max Leske wrote: > BTW, there is a dedicated Fuel mailing list: > pharo-fuel(a)lists.gforge.inria.fr <mailto:pharo-fuel@lists.gforge.inria.fr> > > Max > > >> On 14 Oct 2015, at 09:45, Max Leske <maxleske(a)gmail.com >> <mailto:maxleske@gmail.com>> wrote: >> >>> >>> On 14 Oct 2015, at 04:39, Robert Withers <robert.w.withers(a)gmail.com >>> <mailto:robert.w.withers@gmail.com>> wrote: >>> >>> >>> On 10/13/2015 09:43 PM, Mariano Martinez Peck wrote: >>>> >>>> >>>> On Tue, Oct 13, 2015 at 10:33 PM, Robert Withers >>>> <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com> >>>> <mailto:robert.w.withers@gmail.com>> wrote: >>>> >>>> Hi Mariano, >>>> >>>> This presents me with a big challenge, then. I read the docs and >>>> explored the code and the only other aspect not mentioned, beyond >>>> instance creation (#fuelNew #fuelNew:) and postMaterialization >>>> (#fuelAfterMaterialization), is migrations. However, migration only >>>> allows for instanceVar mappings, no code blocks. >>>> >>>> >>>> What do you mean that migrations only allows instVar mappings , and no >>>> code blocks? I mean, what do you mean by code blocks? >> >> Sounds to me like this (see FuelOutStackDebuAction): >> >> serializeTestFailureContext: aContext toFileNamed: aFilename >> | serializer | >> >> serializer := FLSerializer newDefault. >> self encodeDebugInformationOn: serializer. >> serializer addPostMaterializationAction: [ :materialization | >> Smalltalk tools debugger >> openOn: Processor activeProcess >> context: materialization root >> label: 'External stack' >> contents: nil >> fullView: false ]. >> >> serializer >> " use the sender context, generally the current context is not >> interesting" >> serialize: aContext >> toFileNamed: aFilename >> >> This stores a block in the serialization which is evaluated after >> materialization. The only requirement is that itâs a clean block (no >> closure!). >> >>>> We also support class renames. This is here: >>>> http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Migration?_… >>>> >>>> Which kind of migration example you have in mind that would not be >>>> supported? An example would help. >>> >>> Well, my pics will demonstrate. I am interested in doing more than >>> mappping ivars or a class rename. I want to do a total substitution, >>> then a further substitution on the receiving, import side: >>> >>> Vat1: anObject (Class A) ---> On wire: desc (Descriptor) ---> Vat2: >>> aProxy (Class FarERef) >>> >>> A desc is substituted for a PassByProxy object, then a FarERef is >>> substituted for the desc. >>> >>>> >>>> #fuelAccept: is a serialization side method. >>>> >>>> If Fuel supports substitution on serialization, I don't understand >>>> why no substitution support on materialization. >>>> >>>> >>>> There was a reason, which I cannot remember completely. Maybe Martin or >>>> Max can remember. >>> >>> It seems your focus was pickling to disk then back. My focus is >>> distributed proxy graphs, which has different use cases. >>> >>>> >>>> >>>> I am definitely going to use the world-class Fuel binary >>>> serialization system. However, I find myself needing to extend Fuel >>>> to support substitution on materialization. Perhaps the solution is >>>> a custom decoder. >>>> >>>> >>>> I have made custom clusters for example for my Ghost proxies of Marea >>>> system. It was a perfect example of how I could extent Fuel besides the >>>> common hooks. Fuel provides many places for extending , like clusters, >>>> analyzer, etc >>> >>> Right on, exactly! Could you tell me more about your Ghost proxies >>> and Marea, please? As well, could you mention how you select a custom >>> cluster on the serialization side? >>> >>> >>> thanks so much ^^ >>> Robert >>> >>> >>>> >>>> No, a bit more. It looks like I need a new >>>> FLSubstitutePointerObjectCluster, write them on serialization with >>>> the substitute, then do unsubstitution on materialization, since the >>>> cluster controls materialization and not the decoder. >>>> >>>> Does this approach seem sound to you, from a you know architecture >>>> and design approach? >>>> >>>> >>>> There was an issue. Hope other can remember. If not, I will try to >>>> explan what I remember tomorrow. >>>> >>>> >>>> thanks so much ^^ >>>> Robert >>>> >>>> On 10/13/2015 04:49 PM, Mariano Martinez Peck wrote: >>>> >>>> No, unfortunately, as far as I can remember, we do not have >>>> that. There >>>> are another hooks you may use but only in certain scenarios >>>> (#fuelNew, >>>> #fuelAfterMaterialization, global sends, etc). But everything is >>>> listed >>>> in >>>> http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Customizing… >>>> so if you didn't find anything of help in there there are >>>> chances >>>> there isn't anything. >>>> >>>> Cheers, >>>> >>>> On Tue, Oct 13, 2015 at 5:30 PM, Robert Withers >>>> <robert.w.withers(a)gmail.com >>>> <mailto:robert.w.withers@gmail.com> <mailto:robert.w.withers@gmail.com> >>>> <mailto:robert.w.withers@gmail.com >>>> <mailto:robert.w.withers@gmail.com>>> wrote: >>>> >>>> Yes, I meant dynamic substitution on materialization, to >>>> use the >>>> correct terminology. >>>> >>>> thanks, >>>> Robert >>>> >>>> >>>> On 10/13/2015 11:40 AM, Max Leske wrote: >>>> >>>> >>>> On 13 Oct 2015, at 17:16, Robert Withers >>>> <robert.w.withers(a)gmail.com >>>> <mailto:robert.w.withers@gmail.com> >>>> <mailto:robert.w.withers@gmail.com> >>>> <mailto:robert.w.withers@gmail.com >>>> <mailto:robert.w.withers@gmail.com>>> wrote: >>>> >>>> Every extra source helps, thank you. I see how to do >>>> non-stream substitutions on materializations, but the >>>> documentation did not indicate a way to do non-stream >>>> substitutions on serialization. Is it possible? >>>> >>>> >>>> I donât understand what you mean by ânon-streamâ. Could >>>> you give >>>> an example? >>>> >>>> >>>> thanks, >>>> Robert >>>> >>>> On 10/13/2015 09:00 AM, Mariano Martinez Peck wrote: >>>> >>>> Hi Robert, >>>> >>>> As for the documentation, you have LOTS of >>>> tests, you >>>> have the chapter >>>> Torsten pasted, you have this documentation: >>>> http://rmod.inria.fr/web/software/Fuel >>>> >>>> But also, as for internals, there is a journal >>>> paper we >>>> wrote: >>>> http://rmod.lille.inria.fr/archives/papers/Dias12a-SPE-Fuel.pdf >>>> >>>> Let us know how it goes, >>>> >>>> >>>> On Tue, Oct 13, 2015 at 6:00 AM, Torsten Bergmann >>>> <astares(a)gmx.de <mailto:astares@gmx.de> >>>> <mailto:astares@gmx.de> >>>> <mailto:astares@gmx.de <mailto:astares@gmx.de>> >>>> <mailto:astares@gmx.de <mailto:astares@gmx.de> >>>> <mailto:astares@gmx.de <mailto:astares@gmx.de>>>> wrote: >>>> >>>> Hi Robert, >>>> >>>> Also checkout the chapter on Fuel in Pharo >>>> Enterprise book: >>>> >>>> https://ci.inria.fr/pharo-contribution/view/Books/job/EnterprisePharoBook/l… >>>> >>>> Bye >>>> Torsten >>>> >>>>> Gesendet: Dienstag, 13. Oktober 2015 um >>>> 09:44 Uhr >>>>> Von: "Robert Withers" >>>> <robert.w.withers(a)gmail.com >>>> <mailto:robert.w.withers@gmail.com> >>>> <mailto:robert.w.withers@gmail.com> >>>> <mailto:robert.w.withers@gmail.com >>>> <mailto:robert.w.withers@gmail.com>> >>>> <mailto:robert.w.withers@gmail.com >>>> <mailto:robert.w.withers@gmail.com> >>>> <mailto:robert.w.withers@gmail.com >>>> <mailto:robert.w.withers@gmail.com>>>> >>>>> An: pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> >>>> <mailto:pharo-dev@lists.pharo.org> >>>> <mailto:pharo-dev@lists.pharo.org >>>> <mailto:pharo-dev@lists.pharo.org>> >>>> <mailto:pharo-dev@lists.pharo.org >>>> <mailto:pharo-dev@lists.pharo.org> >>>> <mailto:pharo-dev@lists.pharo.org >>>> <mailto:pharo-dev@lists.pharo.org>>> >>>>> Betreff: Re: [Pharo-dev] binary >>>> serialization >>>>> >>>>> Yes, I have to do object substitutions. >>>> Thanks >>>> for the link! >>>>> >>>>> thanks, >>>>> Robert >>>>> >>>>> On 10/13/2015 03:43 AM, Max Leske wrote: >>>>>> >>>>>>> On 13 Oct 2015, at 09:40, Robert Withers >>>> <robert.w.withers(a)gmail.com >>>> <mailto:robert.w.withers@gmail.com> >>>> <mailto:robert.w.withers@gmail.com> >>>> <mailto:robert.w.withers@gmail.com >>>> <mailto:robert.w.withers@gmail.com>> >>>> <mailto:robert.w.withers@gmail.com >>>> <mailto:robert.w.withers@gmail.com> >>>> <mailto:robert.w.withers@gmail.com >>>> <mailto:robert.w.withers@gmail.com>>>> wrote: >>>>>>> >>>>>>> Sven and Torsten, that's a binary >>>> serialization library! It >>>> will take time to learn it and how to use >>>> mappers. >>>>>>> >>>>>>> What is the format; is it language >>>> neutral? >>>>>> >>>>>> For quick serialization you donât >>>> need to do >>>> anything. It works >>>> for (almost) all objects. Only if you >>>> want to >>>> exclude things or >>>> treat some objects in a special way, you >>>> will need >>>> to do some stuff. >>>>>> >>>>>> Documentation: >>>> http://rmod.inria.fr/web/software/Fuel. >>>>>> >>>>>> >>>>>>> >>>>>>> thanks, >>>>>>> Robert >>>>>>> >>>>>>> On 10/13/2015 01:21 AM, Sven Van >>>> Caekenberghe >>>> wrote: >>>>>>>> Yes, it is called FUEL and it is a >>>> standard >>>> part of the >>>> image. See FLSerializer and FLMaterializer. >>>>>>>> >>>>>>>>> On 13 Oct 2015, at 06:59, Robert >>>> Withers >>>> <robert.w.withers(a)gmail.com >>>> <mailto:robert.w.withers@gmail.com> >>>> <mailto:robert.w.withers@gmail.com> >>>> <mailto:robert.w.withers@gmail.com >>>> <mailto:robert.w.withers@gmail.com>> >>>> <mailto:robert.w.withers@gmail.com >>>> <mailto:robert.w.withers@gmail.com> >>>> <mailto:robert.w.withers@gmail.com >>>> <mailto:robert.w.withers@gmail.com>>>> wrote: >>>>>>>>> >>>>>>>>> Does Pharo have stream classes to >>>> binary >>>> de/serialize an >>>> object, such that the protocol accepts an >>>> object as >>>> an argument and >>>> converts it to a byteArray? >>>>>>>>> >>>>>>>>> -- >>>>>>>>> thanks, >>>>>>>>> Robert >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>> <Exporting Vat.jpg><Importing Vat.jpg> >

Oct. 14, 2015

Re: [Pharo-dev] Question about implementation of a delay

by Ferlicot D. Cyril

Le 14/10/2015 09:01, Henrik Johansen a Ã©crit : > If you by some chance don't like UILoops, and so don't want to make a spinning UILoop inside your UILoop, you could also use a single background thread, something like; > > FilteredDataSource (to be used as dataSource for FastTable, polymorphic api to normal dataSource but redirecting to filteredDataSource variable) > class protocol > filter: aFilter source: aDataSource > ^self new initializeFilter: aFilter source: aDataSource > inst protocol, update related > initializeFilter: aFilterField source: aDataSource > > initialDataSource := filteredDataSource := aDataSource > filterChangeSemaphore := Semaphore new. > self spawnFilterUpdateThread > aFilterField when: ValueChanged send: #updateFilter: to self > > updateFilter: aChangeAnnouncement > "(Probably) runs on UI thread" > pattern := aChangeAnnouncement newValue. > filterChangeSemaphore signal. > > spawnFilterUpdateThread > "Runs in background" > [ | oldPattern | > oldPattern := pattern. > [ filterChangeSemaphore wait. > "If pattern has changed, see if we need to filter. > If not, it's probably an extraneous signal received while we were waiting for 0.2 seconds, and we discard then till we end up waiting for filterChangeSemaphore again" > oldPattern ~= pattern > ifTrue: [ > oldPattern := pattern. > 0.2 seconds wait. > "Pattern still the same? If not, just loop again and end up waiting for another 0.2 secs" > oldPattern = pattern > ifTrue: [ > filteredDataSource := initialDataSource newDataSourceMatching: pattern. > self announce: WhateverChangeAnnouncementBasedOnWhichFastTableSchedulesAViewUpdateForItsDatasource ]]] repeat ] > forkAt: Processor userBackgroundPriority > > Cheers, > Henry > Thank you really much! I tried to get a working version of the widget with the UILoop but that was terrible. But the semaphore work fine. I still need to learn a lot of things about fork, semaphore & co. Thank you for your precious help :) -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Oct. 14, 2015

Re: [Pharo-dev] Question about implementation of a delay

by Henrik Johansen

> On 14 Oct 2015, at 1:32 , Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> wrote: > > Le 14/10/2015 09:01, Henrik Johansen a Ã©crit : >> If you by some chance don't like UILoops, and so don't want to make a spinning UILoop inside your UILoop, you could also use a single background thread, something like; >> >> FilteredDataSource (to be used as dataSource for FastTable, polymorphic api to normal dataSource but redirecting to filteredDataSource variable) >> class protocol >> filter: aFilter source: aDataSource >> ^self new initializeFilter: aFilter source: aDataSource >> inst protocol, update related >> initializeFilter: aFilterField source: aDataSource >> >> initialDataSource := filteredDataSource := aDataSource >> filterChangeSemaphore := Semaphore new. >> self spawnFilterUpdateThread >> aFilterField when: ValueChanged send: #updateFilter: to self >> >> updateFilter: aChangeAnnouncement >> "(Probably) runs on UI thread" >> pattern := aChangeAnnouncement newValue. >> filterChangeSemaphore signal. >> >> spawnFilterUpdateThread >> "Runs in background" >> [ | oldPattern | >> oldPattern := pattern. >> [ filterChangeSemaphore wait. >> "If pattern has changed, see if we need to filter. >> If not, it's probably an extraneous signal received while we were waiting for 0.2 seconds, and we discard then till we end up waiting for filterChangeSemaphore again" >> oldPattern ~= pattern >> ifTrue: [ >> oldPattern := pattern. >> 0.2 seconds wait. >> "Pattern still the same? If not, just loop again and end up waiting for another 0.2 secs" >> oldPattern = pattern >> ifTrue: [ >> filteredDataSource := initialDataSource newDataSourceMatching: pattern. >> self announce: WhateverChangeAnnouncementBasedOnWhichFastTableSchedulesAViewUpdateForItsDatasource ]]] repeat ] >> forkAt: Processor userBackgroundPriority >> >> Cheers, >> Henry >> > > Thank you really much! > I tried to get a working version of the widget with the UILoop but that > was terrible. > But the semaphore work fine. I still need to learn a lot of things about > fork, semaphore & co. > > Thank you for your precious help :) No problem! I also tried to show how to avoid the FilteredDataSource model referencing GUI elements directly, hope you picked up on that as well :) Cheers, Henry

Oct. 14, 2015

Re: [Pharo-dev] Question about implementation of a delay

by Henrik Johansen

If you by some chance don't like UILoops, and so don't want to make a spinning UILoop inside your UILoop, you could also use a single background thread, something like; FilteredDataSource (to be used as dataSource for FastTable, polymorphic api to normal dataSource but redirecting to filteredDataSource variable) class protocol filter: aFilter source: aDataSource ^self new initializeFilter: aFilter source: aDataSource inst protocol, update related initializeFilter: aFilterField source: aDataSource initialDataSource := filteredDataSource := aDataSource filterChangeSemaphore := Semaphore new. self spawnFilterUpdateThread aFilterField when: ValueChanged send: #updateFilter: to self updateFilter: aChangeAnnouncement "(Probably) runs on UI thread" pattern := aChangeAnnouncement newValue. filterChangeSemaphore signal. spawnFilterUpdateThread "Runs in background" [ | oldPattern | oldPattern := pattern. [ filterChangeSemaphore wait. "If pattern has changed, see if we need to filter. If not, it's probably an extraneous signal received while we were waiting for 0.2 seconds, and we discard then till we end up waiting for filterChangeSemaphore again" oldPattern ~= pattern ifTrue: [ oldPattern := pattern. 0.2 seconds wait. "Pattern still the same? If not, just loop again and end up waiting for another 0.2 secs" oldPattern = pattern ifTrue: [ filteredDataSource := initialDataSource newDataSourceMatching: pattern. self announce: WhateverChangeAnnouncementBasedOnWhichFastTableSchedulesAViewUpdateForItsDatasource ]]] repeat ] forkAt: Processor userBackgroundPriority Cheers, Henry > On 13 Oct 2015, at 9:02 , Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> wrote: > > Hi, > > I am building a widget for fast table in order to filter them for > Synectique and Pharo. > > For now I have a Rubric editor where we can write a pattern and I use a > Rubric announcement to update the Fast Table. So each time the rubric is > update the method #update is call. > > At the beginning #update was: > > ---- > pattern := self patternFromString: filterField getText asString trimBoth. > fastTable dataSource: (initialDataSource newDataSourceMatching: pattern). > fastTable refresh > ----- > > But this will update the Fast Table at each character, so I want to add > a delay. > For example I want to let the user type and update the table if he don't > type for 0.2second. > > The only way I found is this: > > ---- > update: anAnnoucement > | pattern timeStamp | > timeStamp := DateAndTime now. > timestamp := timeStamp copy. > [ > (Delay forMilliseconds: 200) wait. > timeStamp = timestamp > ifTrue: [ > pattern := self patternFromString: filterField getText asString trimBoth. > fastTable dataSource: (initialDataSource newDataSourceMatching: pattern). > fastTable refresh ] ] fork > ---- > > But I think that create a new process a each update is really too heavyâ¦ > So I would like to have some advices from experienced people to know if > there is a better way to implement a delay. > > If you want to check the code you can execute: > > ---- > Gofer new > smalltalkhubUser: 'estebanlm' project: 'FastTable'; > configuration; > load. > (Smalltalk globals at: #ConfigurationOfFastTable) loadDevelopment. > FTFastTableComposer browse > ---- > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France >

Oct. 14, 2015

Re: [Pharo-dev] About Magritte Seaside

by Stephan Eggermont

On 14-10-15 08:25, Christophe Demarey wrote: >> What does releasing mean here? Could you frame it in terms of the >> 5D paper and the problems they describe? > > Regarding the 5D paper, what I call release is the version dimension, > where you edit design information. "the designers typically work on a > nonversioned copy of the data files which is kept separate from the > versioned copies stored in the archive" > > the nonversioned copy (in our case is versionned as source code but > not as a release) is what I called the working copy of package > metadata. A released version is a versioned copy of package metadata > published in the package repository. It means a release version has > reach some level of maturity and is ready to use. If I try applying the 5D model, if releasing says something about the maturity level it should be mapped to status. Platform maps to variant, and the package maps to hierarchy. Further in the paper they talk about the interactions between the different dimensions. A conclusion in the paper is that if you want to manage different dimensions, you actually describe a development proces. The needed artifacts and structure follows directly from describing the process(es) you want to support. We want tooling that can support different workflows, as different projects have different needs. That is why I suggested starting from personas and exactly describing how they solve the issues they run into and how they want to work. Stephan

Oct. 14, 2015

Re: [Pharo-dev] binary serialization

by Max Leske

BTW, there is a dedicated Fuel mailing list: pharo-fuel(a)lists.gforge.inria.fr Max > On 14 Oct 2015, at 09:45, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 14 Oct 2015, at 04:39, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> >> On 10/13/2015 09:43 PM, Mariano Martinez Peck wrote: >>> >>> >>> On Tue, Oct 13, 2015 at 10:33 PM, Robert Withers >>> <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: >>> >>> Hi Mariano, >>> >>> This presents me with a big challenge, then. I read the docs and >>> explored the code and the only other aspect not mentioned, beyond >>> instance creation (#fuelNew #fuelNew:) and postMaterialization >>> (#fuelAfterMaterialization), is migrations. However, migration only >>> allows for instanceVar mappings, no code blocks. >>> >>> >>> What do you mean that migrations only allows instVar mappings , and no >>> code blocks? I mean, what do you mean by code blocks? > > Sounds to me like this (see FuelOutStackDebuAction): > > serializeTestFailureContext: aContext toFileNamed: aFilename > | serializer | > > serializer := FLSerializer newDefault. > self encodeDebugInformationOn: serializer. > serializer addPostMaterializationAction: [ :materialization | > Smalltalk tools debugger > openOn: Processor activeProcess > context: materialization root > label: 'External stack' > contents: nil > fullView: false ]. > > serializer > " use the sender context, generally the current context is not interesting" > serialize: aContext > toFileNamed: aFilename > > This stores a block in the serialization which is evaluated after materialization. The only requirement is that itâs a clean block (no closure!). > >>> We also support class renames. This is here: >>> http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Migration?_… >>> >>> Which kind of migration example you have in mind that would not be >>> supported? An example would help. >> >> Well, my pics will demonstrate. I am interested in doing more than mappping ivars or a class rename. I want to do a total substitution, then a further substitution on the receiving, import side: >> >> Vat1: anObject (Class A) ---> On wire: desc (Descriptor) ---> Vat2: aProxy (Class FarERef) >> >> A desc is substituted for a PassByProxy object, then a FarERef is substituted for the desc. >> >>> >>> #fuelAccept: is a serialization side method. >>> >>> If Fuel supports substitution on serialization, I don't understand >>> why no substitution support on materialization. >>> >>> >>> There was a reason, which I cannot remember completely. Maybe Martin or >>> Max can remember. >> >> It seems your focus was pickling to disk then back. My focus is distributed proxy graphs, which has different use cases. >> >>> >>> >>> I am definitely going to use the world-class Fuel binary >>> serialization system. However, I find myself needing to extend Fuel >>> to support substitution on materialization. Perhaps the solution is >>> a custom decoder. >>> >>> >>> I have made custom clusters for example for my Ghost proxies of Marea >>> system. It was a perfect example of how I could extent Fuel besides the >>> common hooks. Fuel provides many places for extending , like clusters, >>> analyzer, etc >> >> Right on, exactly! Could you tell me more about your Ghost proxies and Marea, please? As well, could you mention how you select a custom cluster on the serialization side? >> >> >> thanks so much ^^ >> Robert >> >> >>> >>> No, a bit more. It looks like I need a new >>> FLSubstitutePointerObjectCluster, write them on serialization with >>> the substitute, then do unsubstitution on materialization, since the >>> cluster controls materialization and not the decoder. >>> >>> Does this approach seem sound to you, from a you know architecture >>> and design approach? >>> >>> >>> There was an issue. Hope other can remember. If not, I will try to >>> explan what I remember tomorrow. >>> >>> >>> thanks so much ^^ >>> Robert >>> >>> On 10/13/2015 04:49 PM, Mariano Martinez Peck wrote: >>> >>> No, unfortunately, as far as I can remember, we do not have >>> that. There >>> are another hooks you may use but only in certain scenarios >>> (#fuelNew, >>> #fuelAfterMaterialization, global sends, etc). But everything is >>> listed >>> in >>> http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Customizing… >>> so if you didn't find anything of help in there there are chances >>> there isn't anything. >>> >>> Cheers, >>> >>> On Tue, Oct 13, 2015 at 5:30 PM, Robert Withers >>> <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com> >>> <mailto:robert.w.withers@gmail.com >>> <mailto:robert.w.withers@gmail.com>>> wrote: >>> >>> Yes, I meant dynamic substitution on materialization, to >>> use the >>> correct terminology. >>> >>> thanks, >>> Robert >>> >>> >>> On 10/13/2015 11:40 AM, Max Leske wrote: >>> >>> >>> On 13 Oct 2015, at 17:16, Robert Withers >>> <robert.w.withers(a)gmail.com >>> <mailto:robert.w.withers@gmail.com> >>> <mailto:robert.w.withers@gmail.com >>> <mailto:robert.w.withers@gmail.com>>> wrote: >>> >>> Every extra source helps, thank you. I see how to do >>> non-stream substitutions on materializations, but the >>> documentation did not indicate a way to do non-stream >>> substitutions on serialization. Is it possible? >>> >>> >>> I donât understand what you mean by ânon-streamâ. Could >>> you give >>> an example? >>> >>> >>> thanks, >>> Robert >>> >>> On 10/13/2015 09:00 AM, Mariano Martinez Peck wrote: >>> >>> Hi Robert, >>> >>> As for the documentation, you have LOTS of >>> tests, you >>> have the chapter >>> Torsten pasted, you have this documentation: >>> http://rmod.inria.fr/web/software/Fuel >>> >>> But also, as for internals, there is a journal >>> paper we >>> wrote: >>> http://rmod.lille.inria.fr/archives/papers/Dias12a-SPE-Fuel.pdf >>> >>> Let us know how it goes, >>> >>> >>> On Tue, Oct 13, 2015 at 6:00 AM, Torsten Bergmann >>> <astares(a)gmx.de <mailto:astares@gmx.de> >>> <mailto:astares@gmx.de <mailto:astares@gmx.de>> >>> <mailto:astares@gmx.de <mailto:astares@gmx.de> >>> <mailto:astares@gmx.de <mailto:astares@gmx.de>>>> wrote: >>> >>> Hi Robert, >>> >>> Also checkout the chapter on Fuel in Pharo >>> Enterprise book: >>> >>> https://ci.inria.fr/pharo-contribution/view/Books/job/EnterprisePharoBook/l… >>> >>> Bye >>> Torsten >>> >>>> Gesendet: Dienstag, 13. Oktober 2015 um >>> 09:44 Uhr >>>> Von: "Robert Withers" >>> <robert.w.withers(a)gmail.com >>> <mailto:robert.w.withers@gmail.com> >>> <mailto:robert.w.withers@gmail.com >>> <mailto:robert.w.withers@gmail.com>> >>> <mailto:robert.w.withers@gmail.com >>> <mailto:robert.w.withers@gmail.com> >>> <mailto:robert.w.withers@gmail.com >>> <mailto:robert.w.withers@gmail.com>>>> >>>> An: pharo-dev(a)lists.pharo.org >>> <mailto:pharo-dev@lists.pharo.org> >>> <mailto:pharo-dev@lists.pharo.org >>> <mailto:pharo-dev@lists.pharo.org>> >>> <mailto:pharo-dev@lists.pharo.org >>> <mailto:pharo-dev@lists.pharo.org> >>> <mailto:pharo-dev@lists.pharo.org >>> <mailto:pharo-dev@lists.pharo.org>>> >>>> Betreff: Re: [Pharo-dev] binary >>> serialization >>>> >>>> Yes, I have to do object substitutions. >>> Thanks >>> for the link! >>>> >>>> thanks, >>>> Robert >>>> >>>> On 10/13/2015 03:43 AM, Max Leske wrote: >>>>> >>>>>> On 13 Oct 2015, at 09:40, Robert Withers >>> <robert.w.withers(a)gmail.com >>> <mailto:robert.w.withers@gmail.com> >>> <mailto:robert.w.withers@gmail.com >>> <mailto:robert.w.withers@gmail.com>> >>> <mailto:robert.w.withers@gmail.com >>> <mailto:robert.w.withers@gmail.com> >>> <mailto:robert.w.withers@gmail.com >>> <mailto:robert.w.withers@gmail.com>>>> wrote: >>>>>> >>>>>> Sven and Torsten, that's a binary >>> serialization library! It >>> will take time to learn it and how to use >>> mappers. >>>>>> >>>>>> What is the format; is it language >>> neutral? >>>>> >>>>> For quick serialization you donât >>> need to do >>> anything. It works >>> for (almost) all objects. Only if you want to >>> exclude things or >>> treat some objects in a special way, you >>> will need >>> to do some stuff. >>>>> >>>>> Documentation: >>> http://rmod.inria.fr/web/software/Fuel. >>>>> >>>>> >>>>>> >>>>>> thanks, >>>>>> Robert >>>>>> >>>>>> On 10/13/2015 01:21 AM, Sven Van >>> Caekenberghe >>> wrote: >>>>>>> Yes, it is called FUEL and it is a >>> standard >>> part of the >>> image. See FLSerializer and FLMaterializer. >>>>>>> >>>>>>>> On 13 Oct 2015, at 06:59, Robert >>> Withers >>> <robert.w.withers(a)gmail.com >>> <mailto:robert.w.withers@gmail.com> >>> <mailto:robert.w.withers@gmail.com >>> <mailto:robert.w.withers@gmail.com>> >>> <mailto:robert.w.withers@gmail.com >>> <mailto:robert.w.withers@gmail.com> >>> <mailto:robert.w.withers@gmail.com >>> <mailto:robert.w.withers@gmail.com>>>> wrote: >>>>>>>> >>>>>>>> Does Pharo have stream classes to >>> binary >>> de/serialize an >>> object, such that the protocol accepts an >>> object as >>> an argument and >>> converts it to a byteArray? >>>>>>>> >>>>>>>> -- >>>>>>>> thanks, >>>>>>>> Robert >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >> <Exporting Vat.jpg><Importing Vat.jpg>

Oct. 14, 2015

Re: [Pharo-dev] About Magritte Seaside

by Christophe Demarey

Le 12 oct. 2015 Ã 19:53, Dale Henrichs a Ã©crit : > > > On 10/12/2015 02:58 AM, Christophe Demarey wrote: >> >> Le 11 oct. 2015 Ã 22:32, Dale Henrichs a Ã©crit : >> >>> When you talk about "virtual packages", I would say that a BaselineOf is pretty much a "virtual package" already. >> >> I don't think BaselineOf could be seen as a virtual package. >> In package A, you tell that A depends on V. >> In package B, you simply tell that B provides V. Many other packages could also provide V. >> Then, it is the solver's job to take the most relevant package providing V. > > ah ... I had a different definition of "virtual package" in mind:) >> >>> When it comes to cross-platform support there are several factors that were built into Metacello from the very beginning: >>> >>> - it should be possible to USE a package on a different platform than it was >>> originally written for without modifying the package itself >> >> +1 >> TBH, it is not yet implement in Cargo because I have a dilemnia: once you release a version, you should not edit it anymore. >> On another hand, you would like to say that this package released and validated on Pharo 4 is also valid for Pharo5. >> A good compromise would be to be able to edit only some metadata of a released package. > This is another reason why I think that embedded package dependency is a bad idea .... who controls what meta data gets modified and how do you guarantee integrity. The same concern applies for non-embedded package dependency. You need to control who can modify and who cannot. I do not see your point. > As I consider my response I think I am beginning to see where the difference in our thought processes lie ... > > For example my "virtual package" is defined as a specific commit in a git repository (or any other disk-based SCM) ... the version of the release is defined as the SHA of the commit, or a tag, or a branch name ... in Cargo, I call that an Assembly. It is a set of package units working together. > The components of this virtual package are one or more monticello packages and a BaselineOf.. these components in cargo are package units. > One uses the virtual package by cloning the git repository to the local disk or by using a `github://` description ... > > I choose this approach, because in Smalltalk we typically deal with source code that has to be compiled into our working image ... > > I think that with your "virtual package", you are taking the approach where you are treating the Smalltalk source code as if it were a pre-compiled entity (like linux packages) and the dependencies between projects is more difficult to deal with because you have to worry about the compatibility exeutable binaries ... In the linux world these binary packages need their own dependency mechanisms independent of a development environment so indeed there are very different requirements involved here ... including the need to have dependency specifications independent of the dependency specifications used in the development environment ... > > If this is closer to the truth, then I will have to say that my primary concern today is for development time dependencies and the types of packages that you are talking about with the Cargo Package Manager are aimed at a completely different problem space altogether ... > > BTW, I will read your source code so that I can confirm my supposition ... I think we talk about the same packages but with different words. Virtual packages are just there to allow low-coupling between some packages. I think this could simplify a lot some project dependency definition and save time when you need to update it. Maybe for now, you could just see Cargo managing packages. There package unit and assembly (composite pattern).

Oct. 14, 2015

Re: [Pharo-dev] About Magritte Seaside

by Christophe Demarey

Le 12 oct. 2015 Ã 21:17, Dale Henrichs a Ã©crit : > > > On 10/12/2015 02:58 AM, Christophe Demarey wrote: >> >> Le 11 oct. 2015 Ã 22:32, Dale Henrichs a Ã©crit : >> >> With our approach, metadata lies in the package for the current version and it is on the package repository when the version is released. Platform-specific packages could have their own dependencies. >> What will be possible is to create a new package (not a source code package but a package that is used by a package manager, i.e. metadata) to support a new platform and reusing existing code (by pointing to the package source code). >> Do you have an example to provide to me? >> >>> With all of that said, I really do love the idea of not having to support Metacello anymore:) So I would like to see you succeed with your effort! >> >> It will take time ... >> I would really like to get feedbacks on Cargo because the knowledge you got with Metacello is invaluable. >> >>>>> Perhaps at this point in time, I'd like to read some code. Then I can skip reading the paper and get a feel for how hard it will be to port to GemStone:) >>>> I do not know where christophe save his code but it is be public. >>> I may not have time to read a paper ... but I would have time to read code:) >> >> http://smalltalkhub.com/#!/~demarey/CargoPackageManager <http://smalltalkhub.com/#%21/%7Edemarey/CargoPackageManager> >> > > While I think we might be trying to solve different problems ... I will take a close look at the code in CargoPackageMananger ... too bad, the code isn't on github, because it would be much easier for me to read, comment and contribute:) I have github in mind but did not yet take the plunge. I will see if can do it next days.

Oct. 14, 2015

Re: [Pharo-dev] binary serialization

by Max Leske

> On 14 Oct 2015, at 04:39, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > > On 10/13/2015 09:43 PM, Mariano Martinez Peck wrote: >> >> >> On Tue, Oct 13, 2015 at 10:33 PM, Robert Withers >> <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: >> >> Hi Mariano, >> >> This presents me with a big challenge, then. I read the docs and >> explored the code and the only other aspect not mentioned, beyond >> instance creation (#fuelNew #fuelNew:) and postMaterialization >> (#fuelAfterMaterialization), is migrations. However, migration only >> allows for instanceVar mappings, no code blocks. >> >> >> What do you mean that migrations only allows instVar mappings , and no >> code blocks? I mean, what do you mean by code blocks? Sounds to me like this (see FuelOutStackDebuAction): serializeTestFailureContext: aContext toFileNamed: aFilename | serializer | serializer := FLSerializer newDefault. self encodeDebugInformationOn: serializer. serializer addPostMaterializationAction: [ :materialization | Smalltalk tools debugger openOn: Processor activeProcess context: materialization root label: 'External stack' contents: nil fullView: false ]. serializer " use the sender context, generally the current context is not interesting" serialize: aContext toFileNamed: aFilename This stores a block in the serialization which is evaluated after materialization. The only requirement is that itâs a clean block (no closure!). >> We also support class renames. This is here: >> http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Migration?_… > > > > Which kind of migration example you have in mind that would not be > > supported? An example would help. > > Well, my pics will demonstrate. I am interested in doing more than mappping ivars or a class rename. I want to do a total substitution, then a further substitution on the receiving, import side: > > Vat1: anObject (Class A) ---> On wire: desc (Descriptor) ---> Vat2: aProxy (Class FarERef) > > A desc is substituted for a PassByProxy object, then a FarERef is substituted for the desc. > >> >> #fuelAccept: is a serialization side method. >> >> If Fuel supports substitution on serialization, I don't understand >> why no substitution support on materialization. >> >> >> There was a reason, which I cannot remember completely. Maybe Martin or >> Max can remember. > > It seems your focus was pickling to disk then back. My focus is distributed proxy graphs, which has different use cases. > >> >> >> I am definitely going to use the world-class Fuel binary >> serialization system. However, I find myself needing to extend Fuel >> to support substitution on materialization. Perhaps the solution is >> a custom decoder. >> >> >> I have made custom clusters for example for my Ghost proxies of Marea >> system. It was a perfect example of how I could extent Fuel besides the >> common hooks. Fuel provides many places for extending , like clusters, >> analyzer, etc > > Right on, exactly! Could you tell me more about your Ghost proxies and Marea, please? As well, could you mention how you select a custom cluster on the serialization side? > > > thanks so much ^^ > Robert > > >> >> No, a bit more. It looks like I need a new >> FLSubstitutePointerObjectCluster, write them on serialization with >> the substitute, then do unsubstitution on materialization, since the >> cluster controls materialization and not the decoder. >> >> Does this approach seem sound to you, from a you know architecture >> and design approach? >> >> >> There was an issue. Hope other can remember. If not, I will try to >> explan what I remember tomorrow. >> >> >> thanks so much ^^ >> Robert >> >> On 10/13/2015 04:49 PM, Mariano Martinez Peck wrote: >> >> No, unfortunately, as far as I can remember, we do not have >> that. There >> are another hooks you may use but only in certain scenarios >> (#fuelNew, >> #fuelAfterMaterialization, global sends, etc). But everything is >> listed >> in >> http://rmod.inria.fr/web/software/Fuel/Version1.9/Documentation/Customizing… >> so if you didn't find anything of help in there there are chances >> there isn't anything. >> >> Cheers, >> >> On Tue, Oct 13, 2015 at 5:30 PM, Robert Withers >> <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com> >> <mailto:robert.w.withers@gmail.com >> <mailto:robert.w.withers@gmail.com>>> wrote: >> >> Yes, I meant dynamic substitution on materialization, to >> use the >> correct terminology. >> >> thanks, >> Robert >> >> >> On 10/13/2015 11:40 AM, Max Leske wrote: >> >> >> On 13 Oct 2015, at 17:16, Robert Withers >> <robert.w.withers(a)gmail.com >> <mailto:robert.w.withers@gmail.com> >> <mailto:robert.w.withers@gmail.com >> <mailto:robert.w.withers@gmail.com>>> wrote: >> >> Every extra source helps, thank you. I see how to do >> non-stream substitutions on materializations, but the >> documentation did not indicate a way to do non-stream >> substitutions on serialization. Is it possible? >> >> >> I donât understand what you mean by ânon-streamâ. Could >> you give >> an example? >> >> >> thanks, >> Robert >> >> On 10/13/2015 09:00 AM, Mariano Martinez Peck wrote: >> >> Hi Robert, >> >> As for the documentation, you have LOTS of >> tests, you >> have the chapter >> Torsten pasted, you have this documentation: >> http://rmod.inria.fr/web/software/Fuel >> >> But also, as for internals, there is a journal >> paper we >> wrote: >> http://rmod.lille.inria.fr/archives/papers/Dias12a-SPE-Fuel.pdf >> >> Let us know how it goes, >> >> >> On Tue, Oct 13, 2015 at 6:00 AM, Torsten Bergmann >> <astares(a)gmx.de <mailto:astares@gmx.de> >> <mailto:astares@gmx.de <mailto:astares@gmx.de>> >> <mailto:astares@gmx.de <mailto:astares@gmx.de> >> <mailto:astares@gmx.de <mailto:astares@gmx.de>>>> wrote: >> >> Hi Robert, >> >> Also checkout the chapter on Fuel in Pharo >> Enterprise book: >> >> https://ci.inria.fr/pharo-contribution/view/Books/job/EnterprisePharoBook/l… >> >> Bye >> Torsten >> >> > Gesendet: Dienstag, 13. Oktober 2015 um >> 09:44 Uhr >> > Von: "Robert Withers" >> <robert.w.withers(a)gmail.com >> <mailto:robert.w.withers@gmail.com> >> <mailto:robert.w.withers@gmail.com >> <mailto:robert.w.withers@gmail.com>> >> <mailto:robert.w.withers@gmail.com >> <mailto:robert.w.withers@gmail.com> >> <mailto:robert.w.withers@gmail.com >> <mailto:robert.w.withers@gmail.com>>>> >> > An: pharo-dev(a)lists.pharo.org >> <mailto:pharo-dev@lists.pharo.org> >> <mailto:pharo-dev@lists.pharo.org >> <mailto:pharo-dev@lists.pharo.org>> >> <mailto:pharo-dev@lists.pharo.org >> <mailto:pharo-dev@lists.pharo.org> >> <mailto:pharo-dev@lists.pharo.org >> <mailto:pharo-dev@lists.pharo.org>>> >> > Betreff: Re: [Pharo-dev] binary >> serialization >> > >> > Yes, I have to do object substitutions. >> Thanks >> for the link! >> > >> > thanks, >> > Robert >> > >> > On 10/13/2015 03:43 AM, Max Leske wrote: >> > > >> > >> On 13 Oct 2015, at 09:40, Robert Withers >> <robert.w.withers(a)gmail.com >> <mailto:robert.w.withers@gmail.com> >> <mailto:robert.w.withers@gmail.com >> <mailto:robert.w.withers@gmail.com>> >> <mailto:robert.w.withers@gmail.com >> <mailto:robert.w.withers@gmail.com> >> <mailto:robert.w.withers@gmail.com >> <mailto:robert.w.withers@gmail.com>>>> wrote: >> > >> >> > >> Sven and Torsten, that's a binary >> serialization library! It >> will take time to learn it and how to use >> mappers. >> > >> >> > >> What is the format; is it language >> neutral? >> > > >> > > For quick serialization you donât >> need to do >> anything. It works >> for (almost) all objects. Only if you want to >> exclude things or >> treat some objects in a special way, you >> will need >> to do some stuff. >> > > >> > > Documentation: >> http://rmod.inria.fr/web/software/Fuel. >> > > >> > > >> > >> >> > >> thanks, >> > >> Robert >> > >> >> > >> On 10/13/2015 01:21 AM, Sven Van >> Caekenberghe >> wrote: >> > >>> Yes, it is called FUEL and it is a >> standard >> part of the >> image. See FLSerializer and FLMaterializer. >> > >>> >> > >>>> On 13 Oct 2015, at 06:59, Robert >> Withers >> <robert.w.withers(a)gmail.com >> <mailto:robert.w.withers@gmail.com> >> <mailto:robert.w.withers@gmail.com >> <mailto:robert.w.withers@gmail.com>> >> <mailto:robert.w.withers@gmail.com >> <mailto:robert.w.withers@gmail.com> >> <mailto:robert.w.withers@gmail.com >> <mailto:robert.w.withers@gmail.com>>>> wrote: >> > >>>> >> > >>>> Does Pharo have stream classes to >> binary >> de/serialize an >> object, such that the protocol accepts an >> object as >> an argument and >> converts it to a byteArray? >> > >>>> >> > >>>> -- >> > >>>> thanks, >> > >>>> Robert >> > >>>> >> > >>> >> > >>> >> > >> >> > > >> > > >> > >> > >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com > <Exporting Vat.jpg><Importing Vat.jpg>

Oct. 14, 2015

Re: [Pharo-dev] About Magritte Seaside

by Christophe Demarey

Le 12 oct. 2015 Ã 19:22, Dale Henrichs a Ã©crit : > > > On 10/12/2015 02:20 AM, Christophe Demarey wrote: >> Le 11 oct. 2015 Ã 18:42, Dale Henrichs a Ã©crit : >> >>> >>> On 10/11/15 12:19 AM, stepharo wrote: >>>> >>>> Le 11/10/15 00:40, Dale Henrichs a Ã©crit : >>>>> Christophe, >>>>> >>>>> I still don't have a lot of time to read the paper and try to understand what you are trying to accomplish, >>>> you should read it. :) >>>> We wrote it for that and it is not boring nor long. >>> I scanned through it at the time and as I recall, I thought that the functionality described was already covered by git and BaselineOf ... but I did not read it in great detail and I did not (and still don't) have the time to compose a long-winded response:) >>>>> but I am curious how you think "package dependencies" will play with git-based projects? >>>>> >>>>> In git-based repositories I don't think you have the same type of dependency issues that one might have with monticello repositories --- In a monticello repository you have a whole range of possible package versions to pick from, but in a git-based repository the range of package versions is fixed to those that are committed together so the packages that are meant to work together are committed together. >>>> I think that this is only true for packages committed within the same repo. >>>> Now between porjects published in different repo you have to express them. >>>> I do not think that we all want to publish in the same repo and clone out everything. >>> ... and inter-project dependencies is what a BaselineOf does .... which brings me back to the conclusion that I reached when I scanned the paper:) >>>>> In the bootstrap scenario, you would only have one version per package to choose from, so the packages that are meant to work together are committed together .... >>>>> >>>>> I guess I don't know what you mean when you say: >>>>>> we want to decouple a released version of a package from the working copy of the package version description (implies the creation of a package repository + a web interface on top of it to promote/search packages). >>>>> Perhaps a description of the problem being solved would help me understand. >>>> We want to be able to have a package market place where tools can grab dependencies without to load code >>>> and can compute the set of packages that should be loaded. >>>> >>>> When a package is released into the market: then it externalise its metadata so that a crawler can automatically build >>>> dependency graph and create specific distribution. >>> Okay. This is a problem .... but it happens to be a problem that Metacello "can solve/does solve" - so there must be something else (a deeper problem?) that I don't quite understand. >>> >>> With that said, if you are planning to replace Metacello, then I am excited:) But I will repeat that I hope that you are considering cross platform issues ... >>> >>> Perhaps at this point in time, I'd like to read some code. Then I can skip reading the paper and get a feel for how hard it will be to port to GemStone:) >> Well, the point is not to replace metacello but to go towards a per package metadata description allowing some flexibility with the introduction of virtual packages. > Oh darn, you mean I have to continue to support Metacello:) >> This will allow, in a first time, to set up a package repository and more important, a web site on top of it. In a second time, I also want to enable more flexibility in expressing dependencies constraints (eg. > 2.0, 3.*, etc.). To achieve that, you need a very performant dependency solver and I would like to reuse linux ones (it has be done for ocaml by example) through CUDF (check http://mancoosi.org/ > There are a couple of different schemes for expressing "version ranges" in Metacello. Have you looked at them? No, I did not check on latest Metacello versions. What is supported? > By reuse, do you mean that you will reimplement the algorithms in Smalltalk or are you suggesting that depency resolution will only work on linux? I would like to define the dependency solving as a rest service, so no need to support multiple platforms. the dependency solving can be hosted on linux. > From a practical perspective I am curious what problems will be solved by having "dependency constraints" expressed by anything more complicated than what I use for github: > > github://dalehenrich/tode:v0.0.?/repository > > Which translates to load the latest patch version of the tode project (where major.minor.patch) ... I know that in theory more complicated schemes are intersting, but that assumes that the developers assigning version numbers are actually adhering to a rational version numbering scheme and from a practical matter even the above pattern is risky business:) you're right but we should encourage people to adopt semantic versionning. It's very powerful when semantic versioning policy is applied. >> >> For now, I implemented a simple solver for static dependency constraints (=1.2). I checked Metacello implementation and it looked to me that approaches are a bit too far to be able to reuse the whole code. For sure, it is not as robust as Metacello is, because you enhanced it for years. >> What I want now, is to experiment (let's name it) Cargo Package Manager to see if it fits the needs. Pharo bootstrap is the first use case. > > okay, so this is just in the experimental phases .... so for the time being I should be focussing my efforts on the minimal Metacello approach rather than get involved in the Cargo Package Manager? What I wanted to say is that is still experimental for me because it does not have yet users. Maybe we could take Gemstone and GLASS/GSDevKit package as a use case and see if Cargo fits your needs. I would really enjoy to join forces and have a better solution. What are your requirements for having GLASS/GSDevKit loadable into GemStone. Do you have a deadline? I will have more time starting November (for now, I work on the bootstrap with Max for 2 weeks). Christophe

Oct. 14, 2015