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

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

Re: [Pharo-dev] Pharo needs you

by Robert Withers

Here's the fixed Crypto mcz for Pharo 5. I have not had a chance to submit it but I'm working that item. Here's the old link: http://www.squeaksource.com/Cryptography, with the Plugins code. I lost the link to the Pharo repo Cryptography page. thanks, Robert On 10/13/2015 05:44 PM, Robert Withers wrote: > Hey Stef, > > This discussion got me to thinking about fonts and system-dependent > resources. I wrote SSH and SSL long time back because though there were > both performance issues and validation issues, it was all in the image > and totally platform-independent. I still hold this opinion, in belief > that a few different styles of optimizations are available: JIT, crypto > plugins, shared data. The reasoning is that comm data is platform > independent. > > The situation with fonts is different. Fonts are licensed and I smile in > the thought that they are types, the only types you could ever possibly > want. :) Different platforms have different sets of these types and > they should be available to us, in image. > > Now, that's a lot of work that you may want to spent on other > activities. Ok, could we combine font work with another value? Yeah, I > think so, at least if I were in your shoes. My burning question is "What > is the best way/structure/form to differentiate platforms specifics from > polymorphic interfaces?". I think it is much easier when the form & > structure of the content is platform-independent and is your data-driven > case. Yet in the access, this is platform-dependent and you want it to > be so. Therefor the upper interface - of the access classes - ought to > pass platform-independent instances. > > The conclusion I come to is that the platform-dependent code must > translate across that semantic barrier and talk Smalltalk. Implementing > a case study is highly useful, I would think. An in-image font builder > could publish annotated platform-independent glyph definitions, our > fonts, through platform-dependent libraries, reading these assets off > the system. > > NB: regarding crypto plugins: I'll attach the Cryptography mcz again > along with a CryptographyPlugins mcz. If anyone wanted to try to get > those working in Pharo, that would be educational. This has an > interesting example how to plug platform-dependent plugins in. In fact, > Fuel validation could be used on crypto plugins and different > implementations could be tried using other languages. What's the best? > May be Haskel, right? If some students got into writing crypto plugins > that would also be high value, to me anyways, but I feel it's for us all. > > Thanks so much ^^ > Robert > > On 10/13/2015 05:14 PM, stepharo wrote: >> Thanks Aliaksei. >> >> I think that in the future we should be radically with hardcoded fonts >> and color. >> I think that a widget should have color and font as variables that we >> can set up from the outside. >> What is your take on this. >> >> Stef >> >> >> Le 12/10/15 23:34, Aliaksei Syrel a Ã©crit : >>> >>> Thanks for pointing out such usecase, Stef! This is indeed important >>> >>> On Oct 12, 2015 9:16 PM, "stepharo" >>> <<mailto:stepharo@free.fr>stepharo(a)free.fr> wrote: >>> >>> Hi guys >>> >>> We are working like mad on the mooc and I'm stuck because to >>> produce cool videos I cannot get the correct fonts >>> because the widgets are not using font size :( >>> Look at the attachment. >>> This is how one day we pay our sloppiness. >>> So I will reduce the font size but it sucks. >>> Stef >>> >>

Oct. 13, 2015

Re: [Pharo-dev] Pharo needs you

by Robert Withers

Hey Stef, This discussion got me to thinking about fonts and system-dependent resources. I wrote SSH and SSL long time back because though there were both performance issues and validation issues, it was all in the image and totally platform-independent. I still hold this opinion, in belief that a few different styles of optimizations are available: JIT, crypto plugins, shared data. The reasoning is that comm data is platform independent. The situation with fonts is different. Fonts are licensed and I smile in the thought that they are types, the only types you could ever possibly want. :) Different platforms have different sets of these types and they should be available to us, in image. Now, that's a lot of work that you may want to spent on other activities. Ok, could we combine font work with another value? Yeah, I think so, at least if I were in your shoes. My burning question is "What is the best way/structure/form to differentiate platforms specifics from polymorphic interfaces?". I think it is much easier when the form & structure of the content is platform-independent and is your data-driven case. Yet in the access, this is platform-dependent and you want it to be so. Therefor the upper interface - of the access classes - ought to pass platform-independent instances. The conclusion I come to is that the platform-dependent code must translate across that semantic barrier and talk Smalltalk. Implementing a case study is highly useful, I would think. An in-image font builder could publish annotated platform-independent glyph definitions, our fonts, through platform-dependent libraries, reading these assets off the system. NB: regarding crypto plugins: I'll attach the Cryptography mcz again along with a CryptographyPlugins mcz. If anyone wanted to try to get those working in Pharo, that would be educational. This has an interesting example how to plug platform-dependent plugins in. In fact, Fuel validation could be used on crypto plugins and different implementations could be tried using other languages. What's the best? May be Haskel, right? If some students got into writing crypto plugins that would also be high value, to me anyways, but I feel it's for us all. Thanks so much ^^ Robert On 10/13/2015 05:14 PM, stepharo wrote: > Thanks Aliaksei. > > I think that in the future we should be radically with hardcoded fonts > and color. > I think that a widget should have color and font as variables that we > can set up from the outside. > What is your take on this. > > Stef > > > Le 12/10/15 23:34, Aliaksei Syrel a Ã©crit : >> >> Thanks for pointing out such usecase, Stef! This is indeed important >> >> On Oct 12, 2015 9:16 PM, "stepharo" >> <<mailto:stepharo@free.fr>stepharo(a)free.fr> wrote: >> >> Hi guys >> >> We are working like mad on the mooc and I'm stuck because to >> produce cool videos I cannot get the correct fonts >> because the widgets are not using font size :( >> Look at the attachment. >> This is how one day we pay our sloppiness. >> So I will reduce the font size but it sucks. >> Stef >> >

Oct. 13, 2015