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

Re: [Pharo-dev] Integer>>#putOn:

by Sven Van Caekenberghe

> On 12 Oct 2015, at 14:26, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > I just spotted this: > > > Integer>>#putOn: aStream > > (aStream isBinary ifTrue: [ self asByteArray ] ifFalse: [ self asString]) putOn: aStream IMO, this is not good, implicit (and inefficient) conversions are being done. Why ? What is the exact contract of #putOn: anyway ? If the result should really depend on the argument, double dispatch might be better. > It does not look so bad at the begining, butâ¦ if I do: > > ByteArray streamContents: [ :s | 42 putOn: s ] > > I got an infinite loop. > > I know, it does not look as a very typical case, butâ¦ if Iâm writing to a Socket and I want to use > > mySocket << 255 âIACâ, thatâs exactly what will happen :( > > If I redefine it as: > > Integer>>#putOn: aStream > aStream isBinary ifFalse: [ > self asString putOn: aStream. > ^ self ]. > self asByteArray do: [ :each | aStream nextPut: each ] > > then is okâ¦ > > Would that be a good change? Yeah that looks about right, still weird, but no weirder than before ;-) > Esteban

Oct. 12, 2015

Integer>>#putOn:

by Esteban Lorenzano

Hi, I just spotted this: Integer>>#putOn: aStream (aStream isBinary ifTrue: [ self asByteArray ] ifFalse: [ self asString]) putOn: aStream It does not look so bad at the begining, butâ¦ if I do: ByteArray streamContents: [ :s | 42 putOn: s ] I got an infinite loop. I know, it does not look as a very typical case, butâ¦ if Iâm writing to a Socket and I want to use mySocket << 255 âIACâ, thatâs exactly what will happen :( If I redefine it as: Integer>>#putOn: aStream aStream isBinary ifFalse: [ self asString putOn: aStream. ^ self ]. self asByteArray do: [ :each | aStream nextPut: each ] then is okâ¦ Would that be a good change? Esteban

Oct. 12, 2015

Re: [Pharo-dev] hello

by Max Leske

> On 12 Oct 2015, at 13:53, SebastiÃ¡n Krynski <skrynski(a)gmail.com> wrote: > > Hello my name is SebastiÃ¡n Krynski from Buenos Aires, Argentina. Hi SebastiÃ¡n, welcome! > 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'. > In order to do this I will be modifying the VM and the Compiler . Sound cool! But isnât that the same as a become: b ? I even think that tmp := a. a := b. b := tmp is equivalent, since the VM only interrupts message sends, and in this case only byte code would be generated? Thatâs not my area of expertise, so please correct me. Cheers, Max > > I'm working under the direction of INRIA and Gabriela ArÃ©valo. >

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Thierry Goubier

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? 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 (!). 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? 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. (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 :( Thierry

Oct. 12, 2015

hello

by SebastiÃ¡n Krynski

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'. In order to do this I will be modifying the VM and the Compiler . I'm working under the direction of INRIA and Gabriela ArÃ©valo.

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Stephan Eggermont

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

Oct. 12, 2015

Another pass on catalog web-site (Styling)

by Esteban Lorenzano

Hi, I made another pass on catalog web-site. This time I just enhanced a bit the stylingâ¦ still a lot to do but is looking better and better: http://catalog.pharo.org (you might need a force refresh) But in fact, this announce is just an excuse to remember you to enhance your configurations with catalog information as described here: http://catalog.pharo.org/catalog/note-for-developers Also, if your configuration is proved to work on Pharo 3, 4 or 5, please copy your configuration into that repository, to avoid it to appear under âUnstableâ tag. The Catalog is just as good as the information it provides: there is A LOT of very good packages no one will ever notice (like Aconcagua, for example), that does not provide *any* information and therefore they will never be used :( PLEASE PLEASE PLEASE UPDATE YOUR CONFIGURATIONS! cheers, Esteban

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Christophe Demarey

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. > 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. > - it should be possible to SUBSTITUTE a platform-specific package with > another platform-specific package without modifying either of the packages with virtual packages, it becomes easy > - 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. > > 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 ... 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 Regards, Christophe

Oct. 12, 2015

Re: [Pharo-dev] FilePlugin primitiveFail on Win7 slave

by Max Leske

> On 12 Oct 2015, at 11:25, Martin Dias <tinchodias(a)gmail.com> wrote: > > Hi Max, > > Have you tried to reproduce this problem in other Win7 computer than the slave? I can try in a laptop I have at home. Yes, I did. In my VirtualBox image all the tests are green. > > Martin > > On Fri, Oct 9, 2015 at 5:53 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > Hey guys, is there a known problem with the FilePlugin on the Win7 slave? Whenever I try to delete a file I get a primitiveFailed. > > As you can see in the trace below, Iâm actually even checking for FileNotFound, which means that the file exists but the VM canât perform the operation for some reason. > > > Cheers, > Max > > > > FilePluginPrims(Object)>>primitiveFailed: > FilePluginPrims(Object)>>primitiveFailed > FilePluginPrims>>deleteDirectory: > WindowsStore(DiskStore)>>delete: > FileSystem>>delete: > FileReference>>delete > DeleteVisitor>>visitReference: > DeleteVisitor(FileSystemVisitor)>>visitDirectory: > PostorderGuide>>visit: > Message>>sendTo: > [ self pop sendTo: self ] in PostorderGuide>>show: > PostorderGuide(FileSystemGuide)>>whileNotDoneDo: > PostorderGuide>>show: > PostorderGuide class(FileSystemGuide class)>>show:to:selecting: > DeleteVisitor>>visit: > DeleteVisitor class>>delete: > FileReference(AbstractFileReference)>>deleteAll > [ ref deleteAll ] in [ :ref | > ref exists > ifFalse: [ ^ self ] > ifTrue: > [ [ ref deleteAll ] > on: FileDoesNotExist > do: [ ] "ignore. Seems to be a glitch in the File plugin" ] ] in LGitTestRepository class>>tearDown > BlockClosure>>on:do: > [ :ref | > ref exists > ifFalse: [ ^ self ] > ifTrue: > [ [ ref deleteAll ] > on: FileDoesNotExist > do: [ ] "ignore. Seems to be a glitch in the File plugin" ] ] in LGitTestRepository class>>tearDown > FileReference(Object)>>in: > LGitTestRepository class>>tearDown > LGitBlobTest(LGitTestCase)>>tearDown >

Oct. 12, 2015

Re: [Pharo-dev] FilePlugin primitiveFail on Win7 slave

by Martin Dias

Hi Max, Have you tried to reproduce this problem in other Win7 computer than the slave? I can try in a laptop I have at home. Martin On Fri, Oct 9, 2015 at 5:53 PM, Max Leske <maxleske(a)gmail.com> wrote: > Hey guys, is there a known problem with the FilePlugin on the Win7 slave? > Whenever I try to delete a file I get a primitiveFailed. > > As you can see in the trace below, Iâm actually even checking for > FileNotFound, which means that the file exists but the VM canât perform the > operation for some reason. > > > Cheers, > Max > > > > FilePluginPrims(Object)>>primitiveFailed: > FilePluginPrims(Object)>>primitiveFailed > FilePluginPrims>>deleteDirectory: > WindowsStore(DiskStore)>>delete: > FileSystem>>delete: > FileReference>>delete > DeleteVisitor>>visitReference: > DeleteVisitor(FileSystemVisitor)>>visitDirectory: > PostorderGuide>>visit: > Message>>sendTo: > [ self pop sendTo: self ] in PostorderGuide>>show: > PostorderGuide(FileSystemGuide)>>whileNotDoneDo: > PostorderGuide>>show: > PostorderGuide class(FileSystemGuide class)>>show:to:selecting: > DeleteVisitor>>visit: > DeleteVisitor class>>delete: > FileReference(AbstractFileReference)>>deleteAll > [ ref deleteAll ] in [ :ref | > ref exists > ifFalse: [ ^ self ] > ifTrue: > [ [ ref deleteAll ] > on: FileDoesNotExist > do: [ ] "ignore. Seems to be a glitch in > the File plugin" ] ] in LGitTestRepository class>>tearDown > BlockClosure>>on:do: > [ :ref | > ref exists > ifFalse: [ ^ self ] > ifTrue: > [ [ ref deleteAll ] > on: FileDoesNotExist > do: [ ] "ignore. Seems to be a glitch in > the File plugin" ] ] in LGitTestRepository class>>tearDown > FileReference(Object)>>in: > LGitTestRepository class>>tearDown > LGitBlobTest(LGitTestCase)>>tearDown >

Oct. 12, 2015