- Pharo-dev - lists.pharo.org

[issue tracker] help with reviews needed

by Marcus Denker

Hi, we have lots of issue that stay on the issue tracker far to long as there are not many people actively reviewing/testing/commenting. it would really be helpful to have more people involved. https://pharo.fogbugz.com/f/filters/36/Fixed-to-Review Marcus

Oct. 14, 2015

Re: [Pharo-dev] About Magritte Seaside

by Christophe Demarey

Le 12 oct. 2015 Ã 19:01, Dale Henrichs a Ã©crit : > > > On 10/12/2015 01:42 AM, Christophe Demarey wrote: >> Hi Dale, >> >> Le 11 oct. 2015 Ã 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, but I am curious how you think "package dependencies" will play with git-based projects? >> >> Dependencies are not tied to a Version Control System (monticello, git or whatever). Dependencies are a package concern. >> With a released version, at the end, we need to fech source code from a VCS (as we do not have a shared binary format): these steps are already done by MC*Repository classes, including git. > Yes but I am asking specifically how this link is specified ... in Metacello, you use repository descriptions to identify the source repository. I am curious how you specify these cross repository dependencies ... or do you even support cross-repository dependencies? I also use repository descriptions as in Metacello. Here is an example of serialized metadata of a package with cargo: CGOPackageUnit { #package : #Grease-Core, #description : ''Core package of the Grease library.'', #version : ''1.1.13'', #timestamp : DateAndTime [ ''2015-04-14T14:51:50.116+00:00'' ], #dependencies : [ ], #repositories : [ ''http://smalltalkhub.foo/mc/Seaside/Grease11/main/'' ], #file : ''Grease-Core-JohanBrichau.94'' } >> >>> 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. >> >> Git allows you to easily reference a set of packages working together. It works fine for packages of the same repository but you get back the problem since you deal with packages of other repositories. > right and in Metacello the cross-repository specifications is handled by a project spec: > > spec > baselineOf: 'Seaside' > repository: 'github://SeasideSt/Seaside:v3.2.0/repository' > > In this case the git version is specified as part of the repository spec (v3.2.0 is a git tag) ... it gets back to how do you handle cross repository references? I get metadata on packages at the same central place: the package repository (You could have more that one if needed, e.g. a private package repository). In the package metadata, I have the information to get back the source code artifact (repositories and file fields). >>> 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 .... >> >> For the first step of the bootstrap, it will work but not for next steps where we will split the Pharo image into different projects. > and how are project dependencies handled? It seems that the project dependencies are intimately tied to package dependencies as often the project dependency itself comes from a specific set of packages and needs to be specified at the package level ... in the current implementation, there is no distinction between a project dependency (an external dependency) and a package dependency (an internal dependency, i.e. a dependency to a package of the same project). >> >>> 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. >> >> When you develop, you have a working copy of a package meta-data, including dependencies. Actually, there are current dependencies of the package. You could avoid to refer to specific versions and just point to the package name as your working image should already have packages loaded. (kind of configurationOf baseline) > This is a BaselineOf in Metacello ... and does exactly what you talk about here ... yes >> When you release a version (strong act), then you "freeze" the current working version of the package meta-data and you publish it somewhere (a package repository) so that it becomes available to others. This metadata is not source cod, is easily accessible by tools and it becomes easy to build a web site on top of this to search / promote packages. >> So, the problems I'm trying to solve there are: >> do not be tied to a VCS and do not need to load code to "play" with packages metadata > As I've mentioned in another message, there is no reason other than a lack of tools that the Metacello specifications (ConfigurationOf and BaselineOf) are not stored in XML/JSON/STON files ... I never liked the idea that code had to be loaded, but it was expedient at the time ... I understand >> offer a central place to easily find the package you need (for example, java has http://central.sonatype.org/, php has https://packagist.org/, etc.) > I am curious about your use of the term "package" here ... is this "package" as in Monticello package, no > or "package" as in a collection of packages and project dependencies ... or ConfigurationOf or BaselineOf? package : the unit you want to deliver. It may be a package unit refering to one Monticello package or a package assembly, i.e. a set of package units and so, a set of Monticello packages. >> do not mix preoccupations: I do not want to have metadata of all released versions + working copy of a package at the same place > Have you looked at a BaselineOf? Yes, I like it but it is not available for Monticello. If we did not have Monticello but git instead, life would be easier. > I also don't like the fact that ConfigurationOf has release and version information embedded in it ... but the ConfigurationOf was invented to plug the gap between what was available in the Monticello eco-system and what is available in a full-featured scm like git. good to know historical reasons ;) > The BaselineOf was invented because git was able to take care of all of version relationships and Metacello no longer needed all of that junk. > > If you look at a BaselineOf you will see that it is reduced to a single baseline method with package dependencies specified by name (the entire BaselineOf applies to all of the packages in a directory on disk managed by git or whatever) very simple very compact and very easy to maintain ... the only reason one touches a BaselineOf is to change a dependency.... > > So I think that for what you seem to need all that needs to be done is to define an XML/JSON/STON representation for the data in a BaselineOf ... a generator for a different format could easily be written and could take existing BaselineOf and spit out the data ... But how do you handle dependencies of projects using Monticello?

Oct. 14, 2015

Re: [Pharo-dev] taskbarThumbnail leaks memory?

by Nicolai Hess

2015-10-11 22:21 GMT+02:00 Henrik Nergaard <henrin10(a)student.uia.no>: > > > > > It looks like the taskbarThumbnails might be leaking memory. > > When moving the mouse across the taskbar viewing the different thumbnails > the memory usage increases by quite a lot (viewed in the taskmanager > (Windows) ). > > I made an example script to illustrate the resource usage. > > > > Test scenario: 20 windows; > > 1 Playground, 19 Nautilus browsers (these are minimized). > > > > =============== Create Test Scenario ======================== > > > > 19 timesRepeat: [ > > Nautilus openOnClass: Object. > > World doOneCycle. > > ]. > > World doOneCycle. > > World submorphs > > select: [ :m | > > m isKindOf: NautilusWindow > > ] > > thenDo: [ :m | m minimize ] > > ===== Enumerate the mouse moving from one taskbarButton to the next ======= > > > > | delay | > > > > delay := [ :msToWait | > > | t | > > t := Time now asMilliSeconds. > > [ (Time now asMilliSeconds - t) < msToWait ] > > whileTrue: [ World doOneCycle ]. > > > > ]. > > 20 timesRepeat: [ > > World submorphs > > detect: [:m | m isTaskbar ] > > ifFound: [ :taskbar | > > taskbar orderedTasks collect: > [ :task | > > task morph > > ] > > thenDo: [ :morph | > > | button | > > button := > (taskbar taskButtonOf: morph). > > morph > taskbarButtonEntered: button event: nil in: nil. > > delay value: > 100. > > morph > taskbarButtonLeft: button event: nil in: nil. > > delay value: > 100 > > ] > > ]. > > Smalltalk garbageCollect. > > ]. > > ============================================================ > > > > Results: (Newest Win vm -> Image 50377) > > > > opening the 20 Windows RAM used is 70MB. > > 1 iteration: 93MB > > 20 iterations: 130MB \ 190 MB when garbageCollect is commented out. > > > > Should the resource usage be that high? > No, this looks bad. Maybe this is because every thumbnail creates a new form to draw on. This is not needed in this case, as there is only one thumbnail view visible at time. But I doubt that this is the reason, because we are creating Forms all over the place and the thumbnail view forms aren't special. > (a taskbarThumbnail is deleted before the next one is shown...) > > > > Best regards, > > Henrik > > > > > > > > > > >

Oct. 14, 2015

Re: [Pharo-dev] About Magritte Seaside

by Christophe Demarey

Le 12 oct. 2015 Ã 14:03, Thierry Goubier a Ã©crit : > > 2015-10-12 11:20 GMT+02:00 Christophe Demarey <Christophe.Demarey(a)inria.fr>: > > 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. > 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/) > > > 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. > > > What I would like, is that, at the end, the dependency solver get out of Pharo and that we use already existing linux ones. What will stay into Pharo are packages metadata and the way to load a list of packages. > > This is something I don't understand: why this focus on making this out of Pharo? The focus is not there but I'm not a specialist of Constraint Satisfaction Problems (CSP), I'm not aware of CSP implementation in Pharo and so, I just want to reuse something working fine for years. We are not so much in the community and we should take care to do not have to maintain too many things, especially when it has little added value. > What CUDF shows is that, overall, a package dependency problem can be expressed as a SAT problem which is then solvable by the appropriate solver... For example, in my ubuntu, I see that I have three (!) CUDF dependency solvers (mccf, packup, aspdcup), where mccf can use the following underlying solvers: lpsolve, cbc, Cplex, Gurobi, Glpk, SCIP or WBO (!). right > More interesting is packup, which rely on minisat+. Minisat, with a short search, shows up as 600 lignes of C++ (https://github.com/niklasso/minisat or http://minisat.se/) Why not porting Minisat in Pharo then? could be an idea. Also good to know, all CUDF backends does not have the same speed. I keep that in mind. It would be good to have a CSP solver available in Pharo. > You would simplify your building your dependency issues (no need to link Pharo to yet another external tool which only works on Mac OS X / Linux :( )... And that would make such a solver available for other uses. My idea was to provide the solving facility as a Rest service and so, do not have to care about OS portability. > (I think Metacello could switch to using Minisat if a Smalltalk port was available... ) > > In the mean-time, the number of available CUDF tools in Linux shows probably nice integration issues with dependency loading depending, on some cases, on the solver selected... cool :( oh ... Thanks for this information, Christophe

Oct. 14, 2015

Re: [Pharo-dev] About Magritte Seaside

by Christophe Demarey

Le 12 oct. 2015 Ã 12:53, Stephan Eggermont a Ã©crit : > On 12-10-15 10:42, Christophe Demarey wrote: > >> When you develop, you have a working copy of a package meta-data, including dependencies. Actually, there are current dependencies of the package. You could avoid to refer to specific versions and just point to the package name as your working image should already have packages loaded. (kind of configurationOf baseline) >> When you release a version (strong act), then you "freeze" the current working version of the package meta-data and you publish it somewhere (a package repository) so that it becomes available to others. This metadata is not source cod, is easily accessible by tools and it becomes easy to build a web site on top of this to search / promote packages. > > 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. Christophe

Oct. 14, 2015

Re: [Pharo-dev] [Reflectivity] A small Demo: Execution Metalink Demo Plugin for Nautilus

by Tudor Girba

I do not know about the dog part, but all the rest is so true :) Doru On Tue, Oct 6, 2015 at 3:24 AM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > hahahah terrific! Marcus looks like a dog with two tails :) > Now for real, this is a clear example of a thesis project (Marcus' > Reflexibility) which years ago was a prototype and now, with all the > progress made in Pharo, it can be made for real!!! > > On Mon, Oct 5, 2015 at 2:22 PM, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote: > >> Cool!!!! >> Go go go! >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> On Oct 5, 2015, at 12:27 PM, Miguel Campusano <mcampusa(a)dcc.uchile.cl> >> wrote: >> >> Now I'm making some progress with annotating the unused temp var ;)<Screen >> Shot 2015-10-05 at 17.27.03.png> >> >> On Sun, Oct 4, 2015 at 10:58 AM Marcus Denker <marcus.denker(a)inria.fr> >> wrote: >> >>> >>> On 04 Oct 2015, at 10:47, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> >>> On 04 Oct 2015, at 10:46, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> >>> On 04 Oct 2015, at 08:30, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> >>> On 03 Oct 2015, at 14:16, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> Hi, >>> >>> With Miguel Campusano we build a small demo. >>> >>> >>> Another thing we worked onâ¦ but it needs some more work to be >>> integratable. Visualising >>> links using the side-icon feature of the new editor: >>> >>> >>> would be cool to put this also to quality assistance :) >>> >>> >>> and of course breakpoints ;) >>> >>> >>> Yes! >>> >>> Marcus >>> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 14, 2015

Re: [Pharo-dev] [Moose-dev] Syntax highlighting is missing in Playground and examples

by Tudor Girba

Hi, On Tue, Oct 13, 2015 at 9:48 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > The two issue are not related. This bug appeared because the 'Playground' > view was using PluggableTextMorph which no longer works on in Pharo. > I replaced the editor with rubric and it should work now. > > We should deprecate the renderers based on PluggableTextMorph in glamour. > Yes. > For that we need to: > - deprecate GLMCompositePresentation>>#smalltalkCode and replace it > senders with #pharoMethod and #pharoPlayground > +1 > - switch the the rubric renderer in GLMCompositePresentation>>#text; Or > do we deprecate #text and keep just #rubricText ? > We switch text: to point to the Rubric renderer. > - deprecate all classes that are linked to the PluggableTextMorph > renderer. > +1. Doru > Cheers, > Andrei > > > > > On Tue, Oct 13, 2015 at 6:35 PM, Alexandre Bergel <alexandre.bergel(a)me.com > > wrote: > >> Done >> >> https://pharo.fogbugz.com/f/cases/16781/Syntax-highlighting-is-missing-in-P… >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> On Oct 13, 2015, at 12:54 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Indeed, that is a bug. Could you open a Pharo issue for this? >> >> Cheers, >> Doru >> >> On Tue, Oct 13, 2015 at 4:51 PM, Alexandre Bergel < >> alexandre.bergel(a)me.com> wrote: >> >>> Hi! >>> >>> I see there is a great battle involving Rubric and all its friends is >>> taking place. >>> When I browse an example, I do not have the syntax highlighting. I am >>> using the last version of Moose. >>> >>> <Screen Shot 2015-10-13 at 11.49.53 AM.png> >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 14, 2015

Re: [Pharo-dev] binary serialization

by Robert Withers

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? > 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

Oct. 14, 2015

Re: [Pharo-dev] binary serialization

by Mariano Martinez Peck

On Tue, Oct 13, 2015 at 10:33 PM, Robert Withers <robert.w.withers(a)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? 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. #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. > > 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 > > 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>> 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>> 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>>> 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>>> >> > 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>> >> > 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>>> 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>>> 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

Oct. 14, 2015

Re: [Pharo-dev] binary serialization

by Robert Withers

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. #fuelAccept: is a serialization side method. If Fuel supports substitution on serialization, I don't understand why no substitution support on materialization. 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. 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? 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>> 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>> 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>>> 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>>> > > 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>> > > 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>>> 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>>> 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

Oct. 14, 2015