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

Re: [Pharo-dev] Problems with a large block

by Eliot Miranda

Thanks Henry. Your approach seems much more rational. For example,e, branches are to the start of a byte code sequence, and return addresses are to the start of the byte code following the send. There is no case I can think of when the last byte of a byte code is an important ordinal, not even in cannotReturn: or illegalBytecode:. On Mon, Oct 12, 2015 at 7:37 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > > On 12 Oct 2015, at 3:43 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> > wrote: > > > On 10 Oct 2015, at 10:05 , Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-10-08 23:45 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Hi Nicolai, >> >> On Thu, Oct 8, 2015 at 2:27 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> Hello Eliot, and thanks for your time. >>> >>> >>> In our (pharo) implementation for sourceNodeForPC, we start at the >>> AST-Node of >>> the compiled method, get the IR (IntermediateRepresentation) and scan >>> this sequence of IRNodes >>> until we finally find that one, that maps to the bytecode of the closure >>> creation code (this should be a IRPushClosureCopy). >>> The problem is now, we don't find (always) the right IRNode, and it >>> depens on the number of local temps, if this is > 3 we don't hit the right >>> one. >>> >> >> That's very strange. Can you construct a synthetic example of two simple >> blocks, one with three temps and and one with four temps and show me the >> difference in the byte code? >> > > > [ :x | | a b c | a:=b:=c:=x ] "calling #sourceNode gives a > RBBlockNode - ok" > Bytecode > 13 <8F 01 00 0B> closureNumCopied: 0 numArgs: 1 bytes 17 to 27 > 17 <73> pushConstant: nil > 18 <73> pushConstant: nil > 19 <73> pushConstant: nil > 20 <10> pushTemp: 0 > 21 <81 43> storeIntoTemp: 3 > 23 <81 42> storeIntoTemp: 2 > 25 <81 41> storeIntoTemp: 1 > 27 <7D> blockReturn > 28 <7C> returnTop > > > [ :x | | a b c d | a:=b:=c:=d:=x ] "calling #sourceNode gives a > RBMethodNode - not ok" > Bytecode > 13 <8F 01 00 0E> closureNumCopied: 0 numArgs: 1 bytes 17 to 30 > 17 <73> pushConstant: nil > 18 <73> pushConstant: nil > 19 <73> pushConstant: nil > 20 <73> pushConstant: nil > 21 <10> pushTemp: 0 > 22 <81 44> storeIntoTemp: 4 > 24 <81 43> storeIntoTemp: 3 > 26 <81 42> storeIntoTemp: 2 > 28 <81 41> storeIntoTemp: 1 > 30 <7D> blockReturn > 31 <7C> returnTop > > As I wrote above, in Pharo, to get the sourceNode we try to find the push > closure bytecode from "startpc - 1" by traversing > the IR and try to get the IRNode with matching "bytecodeOffset". The > bytecodeOffsets for the above blocks: > > [ :x | | a b c | a:=b:=c:=x ] > "bytecodeOffset -> IR" > 19->pushClosureCopyCopiedValues: #() args: #(#x) > 28->returnTop > 20->pushTemp: #x > 22->storeTemp: #c > 24->storeTemp: #b > 26->storeTemp: #a > 27->blockReturnTop > > [ :x | | a b c d | a:=b:=c:=d:=x ] > "bytecodeOffset -> IR" > 20->pushClosureCopyCopiedValues: #() args: #(#x) > 31->returnTop > 21->pushTemp: #x > 23->storeTemp: #d > 25->storeTemp: #c > 27->storeTemp: #b > 29->storeTemp: #a > 30->blockReturnTop > > Both blocks don't have a bytecodeOffset matching the bytecode of the > pushclosure (13), but we start the search from "startpc - 1" (= 16) > and do a loop from 0 to -3 (because bytecodes can have a length of 1,2 or > 4) > For the first block, this works > bytecodeOffset 19 = 16 - (-3) > For the second block this does not work, somehow the bytecodeoffset value > depends on the number of local temps. And for the > second block this is one greater. > > > > >> And my interpretation was, the IRPushClosureCopy node has the wrong >>> "bytecode offset" (whatever this is). The bytecodeOffset value (somehow) >>> depends on the number of local temps, but maybe this is right (for >>> whatever this is used) and we are just using it wrong for in this situation. >>> >> >> So you need to ask Marcus how to interpret bytecodeOffset. The thing is, >> it should be simple. One has: >> >> BlockCreationBytecode >> any number of pushConstant: nil's (0 to N) >> first byte code in block >> last bytecode in block (always a blockReturnTop) >> >> and a block's startup is always that of the byte immediately following >> the BlockCreationBytecode. So if the byte code offset is somehow the span >> of the "any number of pushConstant: nil's (0 to N)" then there's a bug in >> the IR somewhere when the number of temps is > 3. But if that's not what >> it means then, well, I don't know what the problem is. >> >> > > For some reason, bytecodeOffset is the *last* byte associated with IR. > This makes little sense to me, the main use seems to be to get correct > offsets for different instructions in an IR sequence. > Since block IR includes temp initialization bytes, the offset is 5. > > Changing the code to record *starting* offset of an IRNode in IRSequence, > by: > mapBytesTo: instr > "Associate the current byte offset with instr. We fix this later to have > the correct offset, > see #bytecodes" > instrMap add: instr -> (bytes size + 1) > > and mapping bytes *before* visiting node in the IRTranslatorV2: > visitInstruction: instr > gen mapBytesTo: instr. > self visitNode: instr. > > and the same in visitPushClosureCopy: closure > closure copiedValues do: [:name | > gen mapBytesTo: closure. > gen pushTemp: (self currentScope indexForVarNamed: name). > ]. > --snip-- > > > Hupps, the pushing of copiedValues are not part of the closure bytecode, > so that needs to be > closure copiedValues do: [:name | > gen pushTemp: (self currentScope indexForVarNamed: name). > ]. > gen mapBytesTo: closure. > > Thanks testBlockAndContextSourceNode! > > After a recompile of the test methods in case of cached IR (and offsets) > (RPackageOrganizer default packageNamed: 'OpalCompiler-Tests') classes > do:#recompile > All (existing) tests are green with the attached change set (where > haltOnce's were removed too), at least in the almost-release version of > Pharo4 I tested in. > > Cheers, > Henry > > > > > > -- _,,,^..^,,,_ best, Eliot

Oct. 12, 2015

Re: [Pharo-dev] [ANN] Cupboard inspector for Teapot

by Attila Magyar

This is very nice thanks, and Cupboard is an awesome name. -- View this message in context: http://forum.world.st/ANN-Cupboard-inspector-for-Teapot-tp4855120p4855188.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

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. 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 ... The components of this virtual package are one or more monticello packages and a BaselineOf.. 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 ... Dale

Oct. 12, 2015

Re: [Pharo-dev] Relation between Garage PG and PGv2

by Esteban A. Maringolo

2015-10-12 14:05 GMT-03:00 Torsten Bergmann <astares(a)gmx.de>: > > Hi Esteban, > > we noticed the same "copy reuse" issue with NBSQlite. > > See this thread: > http://forum.world.st/Garage-and-SQLite-file-databases-general-project-stru… > > which ended up in a different discussion on URLs. I did not really understood > but had not time to look deeper and reproduce Guilles arguments clearly. Yeap, I remember seeing such discussion. But I got on it when it was a discussion about URLs, didn't see the part of the fork. But if it is the same with NBSQlite as it is with PostgresV2 then it's a waste of resources[1], as I suspected, it is not an "common API" for Database connectivity, but instead it is a fork of database drivers to work under a common API using inheritance rather than composition to reach the multi-driver approach. :-/ Regards, Esteban A. Maringolo [1]: It breaks rules #1, #3, #4, #13, #16 and #17 of the unix philosophy :) > Thanks > T. > > > Gesendet: Montag, 12. Oktober 2015 um 16:57 Uhr > Von: "Esteban A. Maringolo" <emaringolo(a)gmail.com> > An: "Pharo Developers" <pharo-dev(a)lists.pharo.org> > Betreff: [Pharo-dev] Relation between Garage PG and PGv2 > > Hi all, and Guille Polito in particular, > > I'm loading the Garage classes into Pharo 4, and I see the Garage-Postgres package "duplicates" the classes of the PostgresV2 package, but instead of using the PG prefix, it uses the GA prefix. This is in particular with the case of Garage-Postgres-Protocol package. > > Why is it so? > > Because even GAConnection>>#buildDefaultConnectionArgs (which is a replica of PGConnection) references PGConnectionArgs instead of GAConnectionArgs, which is the replica of the first. > > > QUESTION: Isn't Garage a "common API" for the *existing* drivers? (like a common wrapper), and if so it delegates the protocol handling to the real driver? In the PostgresV2 package in this case, to PG prefixed classes. > > Regards! > > > Esteban A. Maringolo >

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

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? 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? 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:) > > 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? Dale

Oct. 12, 2015

Re: [Pharo-dev] Relation between Garage PG and PGv2

by Torsten Bergmann

Hi Esteban, we noticed the same "copy reuse" issue with NBSQlite. See this thread: http://forum.world.st/Garage-and-SQLite-file-databases-general-project-stru… which ended up in a different discussion on URLs. I did not really understood but had not time to look deeper and reproduce Guilles arguments clearly.Â Thanks T. Â Gesendet:Â Montag, 12. Oktober 2015 um 16:57 Uhr Von:Â "Esteban A. Maringolo" <emaringolo(a)gmail.com> An:Â "Pharo Developers" <pharo-dev(a)lists.pharo.org> Betreff:Â [Pharo-dev] Relation between Garage PG and PGv2 Hi all, and Guille Polito in particular, Â I'm loading the Garage classes into Pharo 4, and I see the Garage-Postgres package "duplicates" the classes of the PostgresV2 package, but instead of using the PG prefix, it uses the GA prefix. This is in particular with the case of Garage-Postgres-Protocol package. Â Why is it so?Â Â Because even GAConnection>>#buildDefaultConnectionArgs (which is a replica of PGConnection) references PGConnectionArgs instead ofÂ GAConnectionArgs, which is the replica of the first. Â QUESTION: Isn't Garage a "common API" for the *existing* drivers? (like a common wrapper), and if so it delegates the protocol handling to the real driver? In the PostgresV2 package in this case, to PG prefixed classes. Â Regards! Â Â Esteban A. Maringolo

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

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? > >> 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? > >> 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 ... > >> 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 ... > 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 ... > > * 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, or "package" as in a collection of packages and project dependencies ... or ConfigurationOf or BaselineOf? > > * 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? 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. 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 ... Dale

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

On 10/11/2015 11:10 PM, stepharo wrote: > >> >> A BaselineOf has a single baseline method and only the "pure" >> dependencies amongst the packages and projects needs to be expressed >> ... and these dependency specs are about "as small" as you can get ... >>> > Yes but we want them per package. > We do not work on that since more than one year by accident. >>>>> >>>>> 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. >>> But you have to load the configuration and somehow execute it so >>> that it computes the dependencies and we do not want. >> Do you recall that I have been reminding folks that the >> specifications for ConfigurationOf and BaselineOf will someday become >> an XML file? ... I have taken great pains over the years to preserve >> this "expectation" ... Remember the choice to use classes was made as >> a bootstrap convenience to avoid having to create tools ... 6 years >> later and there is still a dearth of tools:) >> >> When you "execute" the code in a ConfigurationOf or BaselineOf, a >> completely separate data structure is constructed using a >> well-defined API and it is this "data structure" that does the real >> work ... it would be very easy to convert a BaselineOf into an >> XML/JSON/STON file without losing any information, unless you've have >> disregarding my warnings:) >> >> There is nothing in Metacello "project specifications" that _depends_ >> upon executing code ... > I know what I meant was use of pragmas, chaining pragma, loading all > the configuration information (different baselines....). > Yeah, I meant that too ... I believe that the entire Metacello specification (ConfigurationOf and BaselineOf) can be represented in an XML/JSON/STON file modulo all of the extra methods that folks have tacked onto the ConfigurationOf for conevenience... but I don't consider that extra stuff part of Metacello ... while chained pragmas, etc. can be represented in XML/JSON/STON files, the primary reason that they are present is to support the ConfigurationOf ... a BaselineOf is typically a single method and doesn't use all of that extra stuff ... >>>> 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 ... >>> Yes we do. First we wanted to make it work. Then we should have kind >>> of virtual packages that act as platforms or project level >> When you talk about "virtual packages", I would say that a BaselineOf >> is pretty much a "virtual package" already. >> >> 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 >> - it should be possible to SUBSTITUTE a platform-specific package with >> another platform-specific package without modifying either of >> the packages >> - it should be possible to CHANGE the package dependencies based on >> platform-dependent requirements without modifying any of the >> packages >> >> The key here is that if one needs to change a package to use it on a >> different platform then you lose the ability to share source code. > > I see well the reason. :) > The last point is the most tricky one when we have per package > dependencies. But I will let christophe answers. It's the reason that I think per package dependencies (at least embedded in the package structure itself) is a bad idea ... it not only gets in the way of cross platform usage, but for the more complicated projects you end up having to touch a bunch of different files to make a "simple dependency change" not to mention having to edit different versions of the same package that may participate in different/conflicting dependency chains ... >> >> The BaselineOf satisfies these requirements, because the "project >> meta data" is separate from the package/source code and the >> BaselineOf itself is cross-platform. >> >> If you haven't thought about these issues from the very beginning, >> then it may not be easy to shoe-horn support in after the fact ... > > I will let christophe answer. >> >> 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! > > Thanks. We will need help definitively. I have been looking at what would need to be done to "port Metacello" to the base GemStone product so that the GLASS/GSDevKit packages could be loaded "directly" into the system, as opposed to the current route, which has a fair amount complicated bootstrapping involved ... I would be using only BaselineOf so the it would not be necessary to port all of Metacello to the base GemStone product ... While I think that I can carve out a "minimal Metacello" it wouldn't be completely free of complication, since I have a commitment to keep the old Metacello functioning and I cannot afford to support two independent versions of Metacello ... If instead I worked with Christophe on this project (and it would meet my needs) then I would save myself a fair amount of work:) And part of that savings would be invested in building a Metacello-bridge to the new packages so that there would be a smooth transition ... > >>>> 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:) > > :) It's the same reason I don't read comments in the code .... when you read the code, you get to see what is actually being done as opposed to what the developer (or comment writer) wants you to think is being done:) Often there is a disparity between what the comment says and what the code does and in my experience the code always seems to win:) Dale

Oct. 12, 2015

[ANN] Pharo Sprint October 23

by marcus.denker＠inria.fr

We will organize a Pharo sprint / Moose dojo Friday, 23th October, starting at 10:00am. (Local Time Lille). It will be at the Inria Lille, Building B, third floor (RMoD offices). Remotely, you can join us on the official IRC channel #pharo on irc.freenode.net <http://irc.freenode.net/> server. During the sprint, we will try to synchronize local and remote Pharo sprinters. As the building is not open to the public, please contact us before if you plan to come.

Oct. 12, 2015

Re: [Pharo-dev] hello

by Thierry Goubier

2015-10-12 16:46 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > > > 2015-10-12 15:33 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> >> On Mon, Oct 12, 2015 at 3:20 PM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> Hi SebastiÃ n, >>> >>> 2015-10-12 13:53 GMT+02:00 SebastiÃ¡n Krynski <skrynski(a)gmail.com>: >>> >>>> Hello my name is SebastiÃ¡n Krynski from Buenos Aires, Argentina. >>>> Just writing to let you know that I'm starting to work on adding an >>>> atomic swap operator in Pharo , guaranteed not to be interrupted by the VM. >>>> The operator will be used this way: >>>> >>>> a :=: b >>>> >>>> meaning 'swap variable a with variable b'. >>>> >>> >>> Why a cryptic, special syntax? The compiler could inline an explicit >>> message send which would make the intent clear. >>> >> >> See previous discussions about <=> indeed. >> >>> >>> a atomicSwapWith: b. >>> >>> Well, anyway, the compiler has to do something special there. >>> >>> Could we have something like... >>> >>> [ | temp | >>> temp := a. >>> a := b. >>> b := a ] atomic >>> >>> ? Would a compiler be able to merge that in a swap instruction? And make >>> another type of processing for a different code inside the block? >>> >> >> We have Mutex>>critical: aBlock etc. >> >> Why not Atomic>>do: aBlock ? >> > > Honestly this block followed by atomic is very confusing IMO. That means > that the compiler has to raise an error if it did not succeed to compile > the block in a single cpu instruction, i.e., a single bytecode that > compiles to a single cpu instruction. For example: > [ | temp | > temp := a. > a := b. > b := a. > self foo ] atomic > has to raise a compilation error as the block cannot be compiled in a > single instruction. Overall very few instructions in specific order can be > compiled in a such a block. > Oh, Clement, compilers can do a lot more than that ;) This one would be easy to do, even if a bit ad-hoc (it's just a simple refactoring pattern to recognize, after all). Let me see... '[ | `x | `x := `y. `y := `z. `z := `x] atomic' RBParseTreeSearcher treeMatching: '[ | `x | `x := `y. `y := `z. `z := `x]' in: (RBParser parseExpression: '[ | temp | temp := a. a := b. b := temp ] atomic') Note that it fails on all the wrong variants you wrote, which leads me to spend more time if I got my pattern right :( But I was considering that it would be either an atomic swap (if the compiler recognize the sequence ... I usually see test_and_set as the primitive, and nowadays everybody saying transactional memory instructions are the way to go) or a critical if it can't be compiled as an atomic instruction (in short, same semantics? but different speeds... I think the trade-off is acceptable) > > Atomic>>#do: can work but the argument block needs to be compiled in a > single instruction so the bytecode compiler has to aware of the syntax > based on the selector anyway. For example, in: > anAtomic do: [ | temp | > temp := a. > a := b. > b := a ] > then the compiler has to compile the block specifically to have single > instruction, even if the call to anAtomic is done in the runtime. > Same as the atomic case above. Atomic should be a singleton; no need to create instances of Atomic, even conceptually. > > On the other hand a new special selector as #atomicSwapWith:, in a similar > way to #ifTrue:ifFalse:, is definitely doable and easy to implement. If you > think it's more readable then it's the way to go. It does not extend the > syntax so I think it can be done like that for the experiment as it is > simpler to implement. > I think this is an important point. Marcus, can something special like that be done via a compiler plugin or a MetaLink? This would be really convenient. Thierry > > > >> >> Would indeed be more readable than :=: >> >> Phil >> >>> >>> >>>> In order to do this I will be modifying the VM and the Compiler . >>>> >>>> Good luck. This is an important step. >>> >>> >>>> I'm working under the direction of INRIA and Gabriela ArÃ©valo. >>>> >>> >>> Welcome! >>> >>> Thierry >>> >> >> >

Oct. 12, 2015