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

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

On 10/14/2015 01:00 AM, Christophe Demarey wrote: > > 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). I agree that at this point in time we have to move beyond descriptions and start looking at source and detailed functionality, because that is where the differences between Cargo and Metacello will manifest themselves ... they are both package managers after all:) Dale

Oct. 14, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

On 10/14/2015 12:48 AM, Christophe Demarey wrote: > 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. That would be awesome as it will make collaboration so much easier! Dale

Oct. 14, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

On 10/14/2015 12:39 AM, Christophe Demarey wrote: > 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? There are a number of operators that can be specified on a project by project basis including ~>[1] ... there never seemed to be a big demand for these operations, presumably because so few developers adhere to a semantic versioning scheme (which makes trying to reason about version numbers very hard) ... and I think that the symbolic version naming convention invented by the Seaside guys: #release3, #release3.1, #release3.2, etc. is superior (from a practical perspective) ... [1] https://robots.thoughtbot.com/rubys-pessimistic-operator > >> 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. So you can't do a build using CargoPackageManager without being connected to the internet ... As I said in another message, I think that you are trying to solve a different problem than Metacello ... there are a number of similarities in the contents of the meta data that is being used (and common specification classes at this level would probably be beneficial), but Metacello is primarily aimed at developers building and using packages produced by others ... I am taking the approach that for developers an SCM (I talk about git all the time, but any disk-based SCM can be used) is part an parcel of of not only developing your own projects but when using other projects, you inevitably have to a) customize them for your own use or b) contribute bugfixes back to the community and an SCM is required for that ... > >> 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). post-November will work best for me as I am targeting a talk on GsDevKit_home and tODE for Smalltalks in November ... I don't have a deadline, but the need to have FileTree and Metacello-lite integrated in the base GemStone is bubbling close to the top ... and post-November would be a good time ... Dale

Oct. 14, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

On 10/14/2015 12:15 AM, Christophe Demarey wrote: > > 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'' > } > I was asking about cross repository dependencies and in this example your #dependencies array is empty ... What repository does the CGOPackageUnit reside in? >>> >>>> 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). So you have a completely separate repository of packages.... On a sort of related note ... you are talking about packages here as if they were a complete unit, but my experience with packages is that they are very rarely completely standlone entities ... Most of my projects involve multiple packages that are tightly coupled to each other ... Am I expected to first register each package in the central repository (or private repository) before I can even think of composing a multi-package project ... I assume that I am missing something here ... > 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). except that they are presumably specified differently? an example specification would be useful here ... > >>> >>>> 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. okay and an assembly of packages looks like? > > >>> * 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. A BaselineOf can be used with a Monticello repository but it devolves to a #bleedingEdge specification which is a nightmare ... Life should be easy ... I guess if your main focus is providing an alternate solution for Monticello repositories then I wish you luck... I don't have the cycles available to try to bridge the gap between Monticello repositories and git repositories ... I prefer to spend my time making git repositories usable with Smalltalk:) > >> 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? > A BaselineOf can specify a dependency on another project and that project may be a BaselineOf or a ConfigurationOf ... A ConfigurationOf can be serialized to STON just like a BaselineOf ... it will just have a lot more junk it ... junk that is managed by git in a git repository ... Dale

Oct. 14, 2015

Re: [Pharo-dev] TestPGConnection>>testNotify2 fails

by Esteban A. Maringolo

Problem Â¿solved? I ran the test against a PostgreSQL 9.2 and the test passed. However the test passes... but it is failing silently, because it should raise a NoticeResponse and it's throwing a PGErrorResponse instead. It seems like this has been buried for years, and because nobody ever complained about it I guess nobody uses it. Regards! Esteban A. Maringolo 2015-10-14 14:20 GMT-03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > I have a failing test in my computer when running the test mentioned > in the subject, I get the following error: "PGConnection has a > defective state machine" > > Stack: > PGConnection(Object)>>error: > PGConnection(PGActiveObject)>>stCantHappen: > PGConnection>>stCantHappen: > PGConnection(PGActiveObject)>>processEvent: > PGConnection(PGActiveObject)>>generateEvent:to: > PGConnection(PGActiveObject)>>saProcessEventsUntil: > PGConnection>>copy:withStream: > TestPGConnection>>testNotify2 > > I tested in my computer with Pharo4, Pharo3 and Pharo2, and I get the > same error in all the images with the latest version of it, and also > with the oldest I could load (in Pharo 2, Name: PostgresV2-Maiano.24). > > My PostgreSQL server version is 9.3.7. > > Does it fail for you too? > > Regards! > > Esteban.

Oct. 14, 2015

Re: [Pharo-dev] what is NativeBoost?

by Max Leske

> On 14 Oct 2015, at 17:20, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > Max, if I were to call a blocking 'select' call for NIO, do you think it would lock the image? Thx Yes. Only callbacks can work asynchronously. > > --- > robert > >> On Oct 14, 2015, at 11:13 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >> >>> On 14 Oct 2015, at 17:01, Robert Withers <robert.w.withers(a)gmail.com> wrote: >>> >>> I ran across it browsing and it looks pretty interesting. It's purpose remains a mystery to to me. >> >> NativeBoost provides an FFI. Itâs used by Athens for example to render the fonts in Pharo using Cairo (http://cairographics.org) >> >> Cheers, >> Max >> >>> >>> -- >>> thanks so much ^^ >>> Robert >> >> >

Oct. 14, 2015

TestPGConnection>>testNotify2 fails

by Esteban A. Maringolo

I have a failing test in my computer when running the test mentioned in the subject, I get the following error: "PGConnection has a defective state machine" Stack: PGConnection(Object)>>error: PGConnection(PGActiveObject)>>stCantHappen: PGConnection>>stCantHappen: PGConnection(PGActiveObject)>>processEvent: PGConnection(PGActiveObject)>>generateEvent:to: PGConnection(PGActiveObject)>>saProcessEventsUntil: PGConnection>>copy:withStream: TestPGConnection>>testNotify2 I tested in my computer with Pharo4, Pharo3 and Pharo2, and I get the same error in all the images with the latest version of it, and also with the oldest I could load (in Pharo 2, Name: PostgresV2-Maiano.24). My PostgreSQL server version is 9.3.7. Does it fail for you too? Regards! Esteban.

Oct. 14, 2015

Re: [Pharo-dev] what is NativeBoost?

by Robert Withers

Well, yes, I have not much use for this in my projects. The example of FFI, however, it great to find. thanks so much ^^ Robert On 10/14/2015 12:48 PM, Dimitris Chloupis wrote: > So to summarise the great thing about NB is that it does assembly code > with pharo syntax, the bad thing about NB is that it does assembly code > with pharo syntax. > > Of course there are not that many people around to be sane enough to > write assembly , so of course it will be removed at some point. > > On Wed, Oct 14, 2015 at 7:36 PM Robert Withers > <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: > > Awesome! SO you can do emulation. That's fantastic. > > thanks so much ^^ > Robert > > On 10/14/2015 12:30 PM, Esteban Lorenzano wrote: > > it allows you to define and execute assembly code in the image. > > > > Esteban > > > >> On 14 Oct 2015, at 18:24, Robert Withers > <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: > >> > >> I'd think there's just as much concern with all the globals. > What does ASMJIT do? a Jit? > >> > >> thanks so much ^^ > >> Robert > >> > >> On 10/14/2015 11:18 AM, Esteban Lorenzano wrote: > >>> but bewareâ¦ ASMJIT part of NB (and wellâ¦ NB it self, that > means) will fade awayâ¦ > >>> it will remain compatible (95% of the cases), but we will > unload itâ¦ there is a lot of maintainability and security concerns > around it. > >>> > >>> Esteban > >>> > >>> > >>>> On 14 Oct 2015, at 17:13, Max Leske <maxleske(a)gmail.com > <mailto:maxleske@gmail.com>> wrote: > >>>> > >>>> > >>>>> On 14 Oct 2015, at 17:01, Robert Withers > <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: > >>>>> > >>>>> I ran across it browsing and it looks pretty interesting. > It's purpose remains a mystery to to me. > >>>> > >>>> NativeBoost provides an FFI. Itâs used by Athens for example > to render the fonts in Pharo using Cairo (http://cairographics.org) > >>>> > >>>> Cheers, > >>>> Max > >>>> > >>>>> > >>>>> -- > >>>>> thanks so much ^^ > >>>>> Robert > >>>>> > >>>> > >>>> > >>> > >>> > >> > > > > >

Oct. 14, 2015

Re: [Pharo-dev] what is NativeBoost?

by Dimitris Chloupis

So to summarise the great thing about NB is that it does assembly code with pharo syntax, the bad thing about NB is that it does assembly code with pharo syntax. Of course there are not that many people around to be sane enough to write assembly , so of course it will be removed at some point. On Wed, Oct 14, 2015 at 7:36 PM Robert Withers <robert.w.withers(a)gmail.com> wrote: > Awesome! SO you can do emulation. That's fantastic. > > thanks so much ^^ > Robert > > On 10/14/2015 12:30 PM, Esteban Lorenzano wrote: > > it allows you to define and execute assembly code in the image. > > > > Esteban > > > >> On 14 Oct 2015, at 18:24, Robert Withers <robert.w.withers(a)gmail.com> > wrote: > >> > >> I'd think there's just as much concern with all the globals. What does > ASMJIT do? a Jit? > >> > >> thanks so much ^^ > >> Robert > >> > >> On 10/14/2015 11:18 AM, Esteban Lorenzano wrote: > >>> but bewareâ¦ ASMJIT part of NB (and wellâ¦ NB it self, that means) will > fade awayâ¦ > >>> it will remain compatible (95% of the cases), but we will unload itâ¦ > there is a lot of maintainability and security concerns around it. > >>> > >>> Esteban > >>> > >>> > >>>> On 14 Oct 2015, at 17:13, Max Leske <maxleske(a)gmail.com> wrote: > >>>> > >>>> > >>>>> On 14 Oct 2015, at 17:01, Robert Withers <robert.w.withers(a)gmail.com> > wrote: > >>>>> > >>>>> I ran across it browsing and it looks pretty interesting. It's > purpose remains a mystery to to me. > >>>> > >>>> NativeBoost provides an FFI. Itâs used by Athens for example to > render the fonts in Pharo using Cairo (http://cairographics.org) > >>>> > >>>> Cheers, > >>>> Max > >>>> > >>>>> > >>>>> -- > >>>>> thanks so much ^^ > >>>>> Robert > >>>>> > >>>> > >>>> > >>> > >>> > >> > > > > > >

Oct. 14, 2015

Re: [Pharo-dev] what is NativeBoost?

by Robert Withers

Awesome! SO you can do emulation. That's fantastic. thanks so much ^^ Robert On 10/14/2015 12:30 PM, Esteban Lorenzano wrote: > it allows you to define and execute assembly code in the image. > > Esteban > >> On 14 Oct 2015, at 18:24, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> I'd think there's just as much concern with all the globals. What does ASMJIT do? a Jit? >> >> thanks so much ^^ >> Robert >> >> On 10/14/2015 11:18 AM, Esteban Lorenzano wrote: >>> but bewareâ¦ ASMJIT part of NB (and wellâ¦ NB it self, that means) will fade awayâ¦ >>> it will remain compatible (95% of the cases), but we will unload itâ¦ there is a lot of maintainability and security concerns around it. >>> >>> Esteban >>> >>> >>>> On 14 Oct 2015, at 17:13, Max Leske <maxleske(a)gmail.com> wrote: >>>> >>>> >>>>> On 14 Oct 2015, at 17:01, Robert Withers <robert.w.withers(a)gmail.com> wrote: >>>>> >>>>> I ran across it browsing and it looks pretty interesting. It's purpose remains a mystery to to me. >>>> >>>> NativeBoost provides an FFI. Itâs used by Athens for example to render the fonts in Pharo using Cairo (http://cairographics.org) >>>> >>>> Cheers, >>>> Max >>>> >>>>> >>>>> -- >>>>> thanks so much ^^ >>>>> Robert >>>>> >>>> >>>> >>> >>> >> > >

Oct. 14, 2015

Re: [Pharo-dev] binary serialization

by Robert Withers

On 10/14/2015 11:37 AM, Mariano Martinez Peck wrote: > > > On Wed, Oct 14, 2015 at 12:09 PM, Robert Withers > <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: > > > On 10/14/2015 11:01 AM, Mariano Martinez Peck wrote: > > Robert, > > As far as I can remember, the problem of substitutions at > materialziation time was because... as you may have read, Fuel first > serializes "objects" and then the references. At materialization, it > first creates the objects and then, on a second step, sets the > references betwen objects. So the problem was WHERE to place the > hook, > at which point in time. If we do it just after objects were created, > then the substitution code would NOT have access to any of the > instVars > of that object. If we do it AFTER objects creation and after objects > references, then there is no easy way to "substitute" which doesn't > involve #become: (because the graph is already constructed) And > you know > that #become: is still terrible slow because it scans full > memory. That > will change in Spur. > > > The trick I learned from Gemstone is to use forwarding proxies, > > > Well, Spur will/does something similar called lazy become. Basically it > lets a forwarding pointer object and then takes advantage of next GC > pass or whatever in order to resolve such proxy in lazy manner. > > looking up into the FLobjectId dictionary (decoder>>objects?) when > stitching the references. When you copy the proxies on substitution, > it stitches normally at reference time. > > > Yes, that could work. The problem is if you need instVars of the object > you want to substitute. Imagine you have a class called Client and > instVar 'age'. And you want to substitute Client with instances of > OldClient if 'age' is > 10. At that point in time, the reference to the > instVar 10 has not yet been filled. Yet, you need to replace the object > at graph construction time. > Ok, so a depth-first, node post-apply would allow ivars to substitute before they are accessed when the container may substitute, lazy as you point out. thanks so much ^^ Robert > > > As for Marea and Ghost, > > Ghost proxies paper: https://hal.inria.fr/hal-01081236/document > Current Ghost repo: http://smalltalkhub.com/#!/~CAR/Ghost > > Marea paper: http://www.jot.fm/issues/issue_2013_01/article2.pdf > Current repo: http://ss3.gemstone.com/ss/Marea.html > > And finally, my PhD thesis: > https://tel.archives-ouvertes.fr/tel-00764991/document > > > Nicely done, sir. I'll check them out, thankyou. > > > Thanks, feel free to ask questions. > > In Marea I needed custom clusters for my proxies because the > serializer > itself sends messages to the objects being serialized. My > proxies would > bring back graphs from a secondary memory. So if I was serializing a > graph that had proxies already, I didn't want that. So I hooked my > custom cluster for proxies that send only a few special messages > to the > proxy that these understand and answer rather than intercept those > messages. > > As for how to extend Fuel for this, I recommend to check the code of > Marea. See categories 'Marea-Serializers' and 'Marea-Proxies'. > I have a Marea one click here: > https://www.dropbox.com/sh/xp8jzyypmz0898j/AACRdHno6V7UfhaJ1ofTPPXva?dl=0 > > Cheers, > > > thanks so much ^^ > Robert > > > > On Wed, Oct 14, 2015 at 11:40 AM, 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: > > 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> > <mailto:pharo-fuel@lists.gforge.inria.fr > <mailto:pharo-fuel@lists.gforge.inria.fr>> > <mailto:pharo-fuel@lists.gforge.inria.fr > <mailto:pharo-fuel@lists.gforge.inria.fr> > <mailto:pharo-fuel@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> > <mailto:maxleske@gmail.com <mailto:maxleske@gmail.com>> > <mailto:maxleske@gmail.com > <mailto:maxleske@gmail.com> <mailto:maxleske@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> > <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: > > > 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 > <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 > <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 > <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 > <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: > > 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 > <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 > <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: > > 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 > <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 > <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 > <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 > <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 > <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 > <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 > <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 > <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 > <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 > <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 > <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 > <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 > <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 > <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 > <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 > <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 > <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 > <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 > <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 > <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> > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > > -- > Mariano > http://marianopeck.wordpress.com

Oct. 14, 2015

Re: [Pharo-dev] what is NativeBoost?

by Esteban Lorenzano

it allows you to define and execute assembly code in the image. Esteban > On 14 Oct 2015, at 18:24, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > I'd think there's just as much concern with all the globals. What does ASMJIT do? a Jit? > > thanks so much ^^ > Robert > > On 10/14/2015 11:18 AM, Esteban Lorenzano wrote: >> but bewareâ¦ ASMJIT part of NB (and wellâ¦ NB it self, that means) will fade awayâ¦ >> it will remain compatible (95% of the cases), but we will unload itâ¦ there is a lot of maintainability and security concerns around it. >> >> Esteban >> >> >>> On 14 Oct 2015, at 17:13, Max Leske <maxleske(a)gmail.com> wrote: >>> >>> >>>> On 14 Oct 2015, at 17:01, Robert Withers <robert.w.withers(a)gmail.com> wrote: >>>> >>>> I ran across it browsing and it looks pretty interesting. It's purpose remains a mystery to to me. >>> >>> NativeBoost provides an FFI. Itâs used by Athens for example to render the fonts in Pharo using Cairo (http://cairographics.org) >>> >>> Cheers, >>> Max >>> >>>> >>>> -- >>>> thanks so much ^^ >>>> Robert >>>> >>> >>> >> >> >

Oct. 14, 2015

Re: [Pharo-dev] what is NativeBoost?

by Robert Withers

I'd think there's just as much concern with all the globals. What does ASMJIT do? a Jit? thanks so much ^^ Robert On 10/14/2015 11:18 AM, Esteban Lorenzano wrote: > but bewareâ¦ ASMJIT part of NB (and wellâ¦ NB it self, that means) will fade awayâ¦ > it will remain compatible (95% of the cases), but we will unload itâ¦ there is a lot of maintainability and security concerns around it. > > Esteban > > >> On 14 Oct 2015, at 17:13, Max Leske <maxleske(a)gmail.com> wrote: >> >> >>> On 14 Oct 2015, at 17:01, Robert Withers <robert.w.withers(a)gmail.com> wrote: >>> >>> I ran across it browsing and it looks pretty interesting. It's purpose remains a mystery to to me. >> >> NativeBoost provides an FFI. Itâs used by Athens for example to render the fonts in Pharo using Cairo (http://cairographics.org) >> >> Cheers, >> Max >> >>> >>> -- >>> thanks so much ^^ >>> Robert >>> >> >> > >

Oct. 14, 2015

Re: [Pharo-dev] Random forest in Pharo

by philippe.back＠highoctane.be

Not sure you would get enough performance on Pharo per se. Xe may be better off leveraging a multicore enabled external lib. Like caret and doMC on R. Le 14 oct. 2015 17:49, "Serge Stinckwich" <serge.stinckwich(a)gmail.com> a Ã©crit : > I don't think so. > > I followup your message on SciSmalltalk mailing-list. > This is something that might interested us ;-) > > > > On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou <damien.cassou(a)inria.fr> > wrote: > > Hi, > > > > did anyone implement a Random Forest algorithm in Pharo? > > > > https://en.wikipedia.org/wiki/Random_forest > > > > -- > > Damien Cassou > > http://damiencassou.seasidehosting.st > > > > "Success is the ability to go from one failure to another without > > losing enthusiasm." --Winston Churchill > > > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

Oct. 14, 2015

Re: [Pharo-dev] Random forest in Pharo

by Serge Stinckwich

I don't think so. I followup your message on SciSmalltalk mailing-list. This is something that might interested us ;-) On Wed, Oct 14, 2015 at 4:54 PM, Damien Cassou <damien.cassou(a)inria.fr> wrote: > Hi, > > did anyone implement a Random Forest algorithm in Pharo? > > https://en.wikipedia.org/wiki/Random_forest > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Oct. 14, 2015

Re: [Pharo-dev] Corporate sponsored popularity

by Esteban A. Maringolo

2015-10-14 12:24 GMT-03:00 Ben Coman <btc(a)openinworld.com>: > Just a passing thought... When comparing the popularity of programming > languages, maybe technological features are less important than > sponsorship by a large tech corporation. > http://insights.dice.com/2015/10/13/apples-swift-is-killing-objective-c/ Interesting. I think it is not corporate sponsorship (as it was with Java or .Net a decade ago) but it is where it is going to run the software that you write. So it's not killing it, just displacing it. Swift is popular because if you want to write modern iOS apps you don't want to learn a language that is obsolete for the platform (it is, Objective-C). The same goes for Java in Android. JavaScript got popular not because of Mozilla or ECMA promoting it, but because it can run on almost any device today. And it is displacing popular "solutions" like Rails and alike, because it is becoming the language to run single-page-apps (Meteor/Ember/Angular, etc.) and to many server side solutions like Node that runs on embedded devices as well. So I don't think it is the promotion of it putting money into marketing but instead the interest of the software developer or company to write software that can be used in many devices as possible. Mobile software (iOS/Android) has taken the end user market share, followed by web apps. Native desktop apps are a niche these days, it's not going to disappear, but it will continue to shrink as the other platforms continue to add features. > Anyhow I don't mind that the masses haven't discovered Pharo. I enjoy it. I don't think that secrecy is something to be proud of, I also enjoy Pharo, but abundance of libraries and frameworks makes you more productive, and to have that you need a bigger community. Whether Pharo is ready to receive a HUGE adoption today, both as software, ecosystem (scm, module distribution, services, etc.) and also social community is a different story. Regards! Esteban A. Maringolo

Oct. 14, 2015

Re: [Pharo-dev] binary serialization

by Mariano Martinez Peck

On Wed, Oct 14, 2015 at 12:09 PM, Robert Withers <robert.w.withers(a)gmail.com > wrote: > > On 10/14/2015 11:01 AM, Mariano Martinez Peck wrote: > >> Robert, >> >> As far as I can remember, the problem of substitutions at >> materialziation time was because... as you may have read, Fuel first >> serializes "objects" and then the references. At materialization, it >> first creates the objects and then, on a second step, sets the >> references betwen objects. So the problem was WHERE to place the hook, >> at which point in time. If we do it just after objects were created, >> then the substitution code would NOT have access to any of the instVars >> of that object. If we do it AFTER objects creation and after objects >> references, then there is no easy way to "substitute" which doesn't >> involve #become: (because the graph is already constructed) And you know >> that #become: is still terrible slow because it scans full memory. That >> will change in Spur. >> > > The trick I learned from Gemstone is to use forwarding proxies, Well, Spur will/does something similar called lazy become. Basically it lets a forwarding pointer object and then takes advantage of next GC pass or whatever in order to resolve such proxy in lazy manner. > looking up into the FLobjectId dictionary (decoder>>objects?) when > stitching the references. When you copy the proxies on substitution, it > stitches normally at reference time. Yes, that could work. The problem is if you need instVars of the object you want to substitute. Imagine you have a class called Client and instVar 'age'. And you want to substitute Client with instances of OldClient if 'age' is > 10. At that point in time, the reference to the instVar 10 has not yet been filled. Yet, you need to replace the object at graph construction time. > > > As for Marea and Ghost, >> >> Ghost proxies paper: https://hal.inria.fr/hal-01081236/document >> Current Ghost repo: http://smalltalkhub.com/#!/~CAR/Ghost >> >> Marea paper: http://www.jot.fm/issues/issue_2013_01/article2.pdf >> Current repo: http://ss3.gemstone.com/ss/Marea.html >> >> And finally, my PhD thesis: >> https://tel.archives-ouvertes.fr/tel-00764991/document >> > > Nicely done, sir. I'll check them out, thankyou. > > Thanks, feel free to ask questions. > In Marea I needed custom clusters for my proxies because the serializer >> itself sends messages to the objects being serialized. My proxies would >> bring back graphs from a secondary memory. So if I was serializing a >> graph that had proxies already, I didn't want that. So I hooked my >> custom cluster for proxies that send only a few special messages to the >> proxy that these understand and answer rather than intercept those >> messages. >> >> As for how to extend Fuel for this, I recommend to check the code of >> Marea. See categories 'Marea-Serializers' and 'Marea-Proxies'. >> I have a Marea one click here: >> https://www.dropbox.com/sh/xp8jzyypmz0898j/AACRdHno6V7UfhaJ1ofTPPXva?dl=0 >> >> Cheers, >> > > thanks so much ^^ > Robert > > >> >> On Wed, Oct 14, 2015 at 11:40 AM, Robert Withers >> <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: >> >> 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> >> <mailto:pharo-fuel@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> >> <mailto:maxleske@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> >> <mailto:robert.w.withers@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 >> <mailto:robert.w.withers@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 >> <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: >> >> 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 >> <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: >> >> 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 >> <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 >> <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 >> <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 >> <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 >> <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 >> <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 >> <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 >> <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 >> <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 >> <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> >> >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > -- Mariano http://marianopeck.wordpress.com

Oct. 14, 2015

Corporate sponsored popularity

by Ben Coman

Just a passing thought... When comparing the popularity of programming languages, maybe technological features are less important than sponsorship by a large tech corporation. Anyhow I don't mind that the masses haven't discovered Pharo. I enjoy it. http://insights.dice.com/2015/10/13/apples-swift-is-killing-objective-c/ cheers -ben

Oct. 14, 2015

Re: [Pharo-dev] what is NativeBoost?

by Robert Withers

Max, if I were to call a blocking 'select' call for NIO, do you think it would lock the image? Thx --- robert > On Oct 14, 2015, at 11:13 AM, Max Leske <maxleske(a)gmail.com> wrote: > > >> On 14 Oct 2015, at 17:01, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> I ran across it browsing and it looks pretty interesting. It's purpose remains a mystery to to me. > > NativeBoost provides an FFI. Itâs used by Athens for example to render the fonts in Pharo using Cairo (http://cairographics.org) > > Cheers, > Max > >> >> -- >> thanks so much ^^ >> Robert > >

Oct. 14, 2015

Re: [Pharo-dev] what is NativeBoost?

by Robert Withers

;-) I knew you had fonts. Somewhere inside, i just had that feeling. Cheers, --- robert > On Oct 14, 2015, at 11:13 AM, Max Leske <maxleske(a)gmail.com> wrote: > > >> On 14 Oct 2015, at 17:01, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> I ran across it browsing and it looks pretty interesting. It's purpose remains a mystery to to me. > > NativeBoost provides an FFI. Itâs used by Athens for example to render the fonts in Pharo using Cairo (http://cairographics.org) > > Cheers, > Max > >> >> -- >> thanks so much ^^ >> Robert > >

Oct. 14, 2015

Re: [Pharo-dev] what is NativeBoost?

by Esteban Lorenzano

but bewareâ¦ ASMJIT part of NB (and wellâ¦ NB it self, that means) will fade awayâ¦ it will remain compatible (95% of the cases), but we will unload itâ¦ there is a lot of maintainability and security concerns around it. Esteban > On 14 Oct 2015, at 17:13, Max Leske <maxleske(a)gmail.com> wrote: > > >> On 14 Oct 2015, at 17:01, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> I ran across it browsing and it looks pretty interesting. It's purpose remains a mystery to to me. > > NativeBoost provides an FFI. Itâs used by Athens for example to render the fonts in Pharo using Cairo (http://cairographics.org) > > Cheers, > Max > >> >> -- >> thanks so much ^^ >> Robert >> > >

Oct. 14, 2015

tests should be green

by Nicolai Hess

Please, someone can look at the Collections-Tests The ReleaseTest complains about testLocalMethodsOfTheClassShouldNotBeRepeatedInItsTraits (These are all Test-subclasses that use traits, but all(!) trait method are compiled in the class instead, this happened after someone moved the Test packages (for bootstrap?) OrderedCollectionTest FloatArrayTest ArrayTest DateTest HeapTest MorphicTextAdapter LinkedListTest DatePrintFormatTester StackTest CheckboxButtonMorph IntervalTest DateAndTimeTest SimpleButtonMorph MethodDictionaryTest SetTest DictionaryTest BagTest SymbolTest StringTest CollectionRootTest SortedCollectionTest

Oct. 14, 2015

Re: [Pharo-dev] what is NativeBoost?

by Max Leske

> On 14 Oct 2015, at 17:01, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > I ran across it browsing and it looks pretty interesting. It's purpose remains a mystery to to me. NativeBoost provides an FFI. Itâs used by Athens for example to render the fonts in Pharo using Cairo (http://cairographics.org) Cheers, Max > > -- > thanks so much ^^ > Robert >

Oct. 14, 2015

Broken examples (GLMExamplesBrowser) issue 16111

by Nicolai Hess

I think some examples in GLMExamplesBrowser In Pharo5.0 are broken. see fogbugz issue "16111 Collections being passed as a whole into blocks, instead of each individual object" The confusion about "display-block" and "format-block" is sorted out, so we could close the issue. But it seems the examples "Updateable browser" "Validating presentation" are broken (and maybe the Magritte example, but I don't know where it is).

Oct. 14, 2015

Re: [Pharo-dev] binary serialization

by Robert Withers

On 10/14/2015 11:01 AM, Mariano Martinez Peck wrote: > Robert, > > As far as I can remember, the problem of substitutions at > materialziation time was because... as you may have read, Fuel first > serializes "objects" and then the references. At materialization, it > first creates the objects and then, on a second step, sets the > references betwen objects. So the problem was WHERE to place the hook, > at which point in time. If we do it just after objects were created, > then the substitution code would NOT have access to any of the instVars > of that object. If we do it AFTER objects creation and after objects > references, then there is no easy way to "substitute" which doesn't > involve #become: (because the graph is already constructed) And you know > that #become: is still terrible slow because it scans full memory. That > will change in Spur. The trick I learned from Gemstone is to use forwarding proxies, looking up into the FLobjectId dictionary (decoder>>objects?) when stitching the references. When you copy the proxies on substitution, it stitches normally at reference time. > As for Marea and Ghost, > > Ghost proxies paper: https://hal.inria.fr/hal-01081236/document > Current Ghost repo: http://smalltalkhub.com/#!/~CAR/Ghost > > Marea paper: http://www.jot.fm/issues/issue_2013_01/article2.pdf > Current repo: http://ss3.gemstone.com/ss/Marea.html > > And finally, my PhD thesis: > https://tel.archives-ouvertes.fr/tel-00764991/document Nicely done, sir. I'll check them out, thankyou. > In Marea I needed custom clusters for my proxies because the serializer > itself sends messages to the objects being serialized. My proxies would > bring back graphs from a secondary memory. So if I was serializing a > graph that had proxies already, I didn't want that. So I hooked my > custom cluster for proxies that send only a few special messages to the > proxy that these understand and answer rather than intercept those > messages. > > As for how to extend Fuel for this, I recommend to check the code of > Marea. See categories 'Marea-Serializers' and 'Marea-Proxies'. > I have a Marea one click here: > https://www.dropbox.com/sh/xp8jzyypmz0898j/AACRdHno6V7UfhaJ1ofTPPXva?dl=0 > > Cheers, thanks so much ^^ Robert > > > On Wed, Oct 14, 2015 at 11:40 AM, Robert Withers > <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: > > 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> > <mailto:pharo-fuel@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> > <mailto:maxleske@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> > <mailto:robert.w.withers@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 > <mailto:robert.w.withers@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 > <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: > > 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 > <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: > > 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 > <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 > <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 > <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 > <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 > <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 > <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 > <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 > <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 > <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 > <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> > > > > > > > -- > Mariano > http://marianopeck.wordpress.com

Oct. 14, 2015

Re: [Pharo-dev] binary serialization

by Mariano Martinez Peck

Robert, As far as I can remember, the problem of substitutions at materialziation time was because... as you may have read, Fuel first serializes "objects" and then the references. At materialization, it first creates the objects and then, on a second step, sets the references betwen objects. So the problem was WHERE to place the hook, at which point in time. If we do it just after objects were created, then the substitution code would NOT have access to any of the instVars of that object. If we do it AFTER objects creation and after objects references, then there is no easy way to "substitute" which doesn't involve #become: (because the graph is already constructed) And you know that #become: is still terrible slow because it scans full memory. That will change in Spur. As for Marea and Ghost, Ghost proxies paper: https://hal.inria.fr/hal-01081236/document Current Ghost repo: http://smalltalkhub.com/#!/~CAR/Ghost Marea paper: http://www.jot.fm/issues/issue_2013_01/article2.pdf Current repo: http://ss3.gemstone.com/ss/Marea.html And finally, my PhD thesis: https://tel.archives-ouvertes.fr/tel-00764991/document In Marea I needed custom clusters for my proxies because the serializer itself sends messages to the objects being serialized. My proxies would bring back graphs from a secondary memory. So if I was serializing a graph that had proxies already, I didn't want that. So I hooked my custom cluster for proxies that send only a few special messages to the proxy that these understand and answer rather than intercept those messages. As for how to extend Fuel for this, I recommend to check the code of Marea. See categories 'Marea-Serializers' and 'Marea-Proxies'. I have a Marea one click here: https://www.dropbox.com/sh/xp8jzyypmz0898j/AACRdHno6V7UfhaJ1ofTPPXva?dl=0 Cheers, On Wed, Oct 14, 2015 at 11:40 AM, Robert Withers <robert.w.withers(a)gmail.com > wrote: > 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> >>>> >>> >> > -- Mariano http://marianopeck.wordpress.com

Oct. 14, 2015

what is NativeBoost?

by Robert Withers

I ran across it browsing and it looks pretty interesting. It's purpose remains a mystery to to me. -- thanks so much ^^ Robert

Oct. 14, 2015

Random forest in Pharo

by Damien Cassou

Hi, did anyone implement a Random Forest algorithm in Pharo? https://en.wikipedia.org/wiki/Random_forest -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Oct. 14, 2015

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

[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

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