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

Re: [Pharo-dev] binary serialization

by Robert Withers

Hi Stefan, On 10/24/2015 04:16 AM, Stefan Marr wrote: > Hi Robert: > >> On 22 Oct 2015, at 15:11, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> My thoughts in the VM are to add a pool to the stack and the queue of an event-loop. For processes/continuations what are waiting for a signal, they are not scheduled into the queue. I believe that this model is a good one for a single-image-threaded execution machinery: a scheduling event-loop. This is pure intuition. > There is no need for changing the VM, it is already doing that. When a process is blocked on a semaphore, it is not on the scheduler queue, but on the semaphore, and will only be scheduled once the semaphore has been signaled. With an event-loop as the core construct of the VM, hypothetically speaking from my intution, the async FFI and threeaded VM would have a structural solution. This context changes the mechanics of semaphores, I think. As well semaphores are how the VM signals into Pharo/Squeak so they would definitely change. > Pharo/Smalltalk brings all the basics for implementing the model, except any form of strong guarantee for isolation between vats. But thatâs the usual restriction with libraries, so, shouldnât come as a surprise. > > (Also, Smalltalkâs classes really do not play well with vats. What about their state for instance?) Yes, indeed. Globals are a security evil. Newspeak gets this right. If Squeak went to hierarchical namespaces, changed literal lookup and eliminated Globals, it would be much more secure I think. Robert > > Best regards > Stefan > >> Best, >> Robert >> >>> Stef

Oct. 24, 2015

Re: [Pharo-dev] binary serialization

by Robert Withers

Hi stepharo, I was looking for tom van cutsem's PhD, since you mentioned it, but did not find it. Do you have a link? I am attaching my business plan to you, to answer your question asking what is my goal. That's high-level. Low-level, what I am doing: I require an object-capability system, so I am reconstituting SqueakElib and will be looking at VM and networking areas to fully support capabilities and piconet formation. Robert On 10/24/2015 03:43 AM, stepharo wrote: > Hi robert > > thanks for refreshing me (I read E some year ago) and I read the PhD > of tom van cutsem. > Now what are you doing? What is your goal? > > Stef > > Le 22/10/15 15:11, Robert Withers a Ã©crit : >> >> >> On 10/22/2015 06:19 AM, stepharo wrote: >>> > >>>> > 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'm interesting in knowing more :) >>> Especially Vat and others. >> >> Firstly, I should credit these ideas: I leaned of Elib 9 years ago, >> from http://erights.org. >> >> A vat is an event-loop. This ensures single-threading with only one >> thread executing a stack as it schedules to activity. A vat is >> conceptually a stack and a queue. This is an executing stack of >> immediate calls and a queue of eventual sends that will be scheduled >> into the stack as evaluates. When you have a farReference to an >> object in a different vat, then you need to serialize the graph of >> arguments sent to the remote object with an eventual send: to queue >> the send in the remote vat, pending evaluation as a stack. >> >> When a graph is serialized, any PassByProxy objects sent as an >> argument to a remote method evaluation must be substituted on >> serialization with a descriptor describing the export of that far >> reference. This descriptor substitution is not a Fuel migration >> between versions of one object class nor is it a Fuel substitution, >> which replaces a subset of ivars, it is a true substitution, a >> descriptor of class FarDescriptor replaced for an arbitrary >> PasssByProxy object...let's say Customer <name, age, lastFourSSN>. So >> aCustomer <name: "Robert", age: 45, lastFourSSN: 9876> will get >> substituted with aFarReferenceDesc <wireId: 1, wireCount: 1>. On the >> receiving side, who sees this FerReference, if gets substituted again >> for a FarRef. >> >> aCustomer ---> farDesc ---> farRef >> >> Does this help to answer your questions? Fire away with more >> questions and I will try to answer. Reading about Elib on the erights >> site is another great source of information, sicne these guys came up >> with it. >> >> My thoughts in the VM are to add a pool to the stack and the queue of >> an event-loop. For processes/continuations what are waiting for a >> signal, they are not scheduled into the queue. I believe that this >> model is a good one for a single-image-threaded execution machinery: >> a scheduling event-loop. This is pure intuition. >> >> Best, >> Robert >> >>> Stef >>> >>> >>> >> >> >> > >

Oct. 24, 2015

Re: [Pharo-dev] binary serialization

by Stefan Marr

Hi Robert: > On 22 Oct 2015, at 15:11, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > My thoughts in the VM are to add a pool to the stack and the queue of an event-loop. For processes/continuations what are waiting for a signal, they are not scheduled into the queue. I believe that this model is a good one for a single-image-threaded execution machinery: a scheduling event-loop. This is pure intuition. There is no need for changing the VM, it is already doing that. When a process is blocked on a semaphore, it is not on the scheduler queue, but on the semaphore, and will only be scheduled once the semaphore has been signaled. Pharo/Smalltalk brings all the basics for implementing the model, except any form of strong guarantee for isolation between vats. But thatâs the usual restriction with libraries, so, shouldnât come as a surprise. (Also, Smalltalkâs classes really do not play well with vats. What about their state for instance?) Best regards Stefan > > Best, > Robert > >> Stef -- Stefan Marr Johannes Kepler UniversitÃ¤t Linz http://stefan-marr.de/research/

Oct. 24, 2015

Re: [Pharo-dev] binary serialization

by stepharo

Hi robert thanks for refreshing me (I read E some year ago) and I read the PhD of tom van cutsem. Now what are you doing? What is your goal? Stef Le 22/10/15 15:11, Robert Withers a Ã©crit : > > > On 10/22/2015 06:19 AM, stepharo wrote: >> > >>> > 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'm interesting in knowing more :) >> Especially Vat and others. > > Firstly, I should credit these ideas: I leaned of Elib 9 years ago, > from http://erights.org. > > A vat is an event-loop. This ensures single-threading with only one > thread executing a stack as it schedules to activity. A vat is > conceptually a stack and a queue. This is an executing stack of > immediate calls and a queue of eventual sends that will be scheduled > into the stack as evaluates. When you have a farReference to an object > in a different vat, then you need to serialize the graph of arguments > sent to the remote object with an eventual send: to queue the send in > the remote vat, pending evaluation as a stack. > > When a graph is serialized, any PassByProxy objects sent as an > argument to a remote method evaluation must be substituted on > serialization with a descriptor describing the export of that far > reference. This descriptor substitution is not a Fuel migration > between versions of one object class nor is it a Fuel substitution, > which replaces a subset of ivars, it is a true substitution, a > descriptor of class FarDescriptor replaced for an arbitrary > PasssByProxy object...let's say Customer <name, age, lastFourSSN>. So > aCustomer <name: "Robert", age: 45, lastFourSSN: 9876> will get > substituted with aFarReferenceDesc <wireId: 1, wireCount: 1>. On the > receiving side, who sees this FerReference, if gets substituted again > for a FarRef. > > aCustomer ---> farDesc ---> farRef > > Does this help to answer your questions? Fire away with more questions > and I will try to answer. Reading about Elib on the erights site is > another great source of information, sicne these guys came up with it. > > My thoughts in the VM are to add a pool to the stack and the queue of > an event-loop. For processes/continuations what are waiting for a > signal, they are not scheduled into the queue. I believe that this > model is a good one for a single-image-threaded execution machinery: a > scheduling event-loop. This is pure intuition. > > Best, > Robert > >> Stef >> >> >> > > >

Oct. 24, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50404 Home: https://github.com/pharo-project/pharo-core

Oct. 24, 2015

[pharo-project/pharo-core] 83a31e: 50404

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 83a31e558ab151d52af4661977cb5eb3543484f6 https://github.com/pharo-project/pharo-core/commit/83a31e558ab151d52af46619… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-24 (Sat, 24 Oct 2015) Changed paths: A AST-Core.package/RBVariableNode.class/instance/accessing/startForReplacement.st A AST-Tests-Core.package/RBVariableNodeTest.class/README.md A AST-Tests-Core.package/RBVariableNodeTest.class/definition.st A AST-Tests-Core.package/RBVariableNodeTest.class/instance/tests/testStartForReplacement.st A AST-Tests-Core.package/RBVariableNodeTest.class/instance/tests/testStartForReplacement02.st A CodeExport.package/extension/TClassDescription/instance/fileOutLocalMethodsInCategory_on_.st M CodeExport.package/extension/TClassDescription/instance/fileOutOn_.st A CodeExport.package/extension/TClassDescription/instance/isLocalSelector_.st M ConfigurationOfVersionner.package/ConfigurationOfVersionner.class/instance/symbolic versions/stable_.st A ConfigurationOfVersionner.package/ConfigurationOfVersionner.class/instance/versions/version2136_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/assertCollection_equals_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/assertCollection_hasSameElements_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/assert_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/assert_description_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/assert_description_resumable_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/assert_equals_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/classForTestResult.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/deny_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/deny_description_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/deny_description_resumable_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/executeShould_inScopeOf_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/executeShould_inScopeOf_withDescriptionContaining_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/executeShould_inScopeOf_withDescriptionNotContaining_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/executeShould_inScopeOf_withExceptionDo_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/fail.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/fail_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/shouldFix_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/should_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/should_description_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/should_notTakeMoreThanMilliseconds_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/should_notTakeMoreThan_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/should_raise_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/should_raise_description_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/should_raise_whoseDescriptionDoesNotInclude_description_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/should_raise_whoseDescriptionIncludes_description_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/should_raise_withExceptionDo_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/shouldnt_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/shouldnt_description_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/shouldnt_raise_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/shouldnt_raise_description_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/shouldnt_raise_whoseDescriptionDoesNotInclude_description_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/shouldnt_raise_whoseDescriptionIncludes_description_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/signalFailure_.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/skip.st R Kernel-Tests.package/DatePrintFormatTester.class/instance/asserting/skipUnless_.st M Kernel.package/Object.class/instance/asserting/assert_.st M OpalCompiler-Core.package/OCUnusedVariableWarning.class/instance/correcting/defaultAction.st M SUnit-Core.package/TAssertable.class/instance/asserting/assert_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50403.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50404.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50403.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50404.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Versionner-Tests-Core-Commands.package/VSReleaseDevelopmentVersionCommandTest.class/instance/tests/testResolveSymbolicVersionsIn.st Log Message: ----------- 50404 16847 assert: should not raise an error with a non-boolean argument https://pharo.fogbugz.com/f/cases/16847 16859 Automatic removing of temporary variable leaves a blank character https://pharo.fogbugz.com/f/cases/16859 10808 Bad behavior on FileOut/FileIn tool when using traits https://pharo.fogbugz.com/f/cases/10808 16536 Fix VSReleaseDevelopmentVersionCommandTest>>#testResolveSymbolicVersionsIn https://pharo.fogbugz.com/f/cases/16536 http://files.pharo.org/image/50/50404.zip

Oct. 24, 2015

Re: [Pharo-dev] powerSet

by stepharo

We tried to port this code to python and I learned that we cannot have a set containing a set :( and other uglies like len(str) but not str.len() Stef Le 22/10/15 22:58, stepharo a Ã©crit : > Hi > > I was programming an exercise with one of my son (well in Python.... > arghhhhhh) > and I end it up doing it in Pharo (I'm save now). > > The idea was to write one function that computes the powerset > > powerset(4) > = a Set(a Set(1) a Set(1 2) a Set(3) a Set(2) a Set(1 3) a Set(2 > 3) a Set(1 2 3) a Set(4) a Set(1 4) a Set(2 4) a Set(1 2 4) a Set(3 4) > a Set(1 3 4) a Set(2 3 4) a Set(1 2 3 4)) > > I did it without thinking too much in fact > > | s n ps | > ps := Set new. > > 1 to: ((2 raisedTo: 4) -1) > do: [ :i | > s := Set new. > n := 0. > 1 to: 4 do: [ :b | > n := n + 1. > ((i bitAt: b) = 1 ) > ifTrue: [ s add: n]. > ps add: s ]]. > ps > > but I wonder if we want to add it to our lib. > > Stef > >

Oct. 24, 2015

Re: [Pharo-dev] String>>#expandMacros new line macro rationale

by stepharo

Hi gabriel > > <n> macro is expanded to CR. I was expecting that expands to the line > ending of the platform, or at least to LF. > > Anybody knows if this have some explanation? > > I'm tempted to change the <n> expansion to use OSPlatform current > lineEnding , and add <r> as a valid macro expanding to CR. I think > it's more consistent with the general use. Yes > What do you think? If there's consensus I would create an issue and > provide a Slice with the changes and some test cases. Yes I would love that someone or a group of Pharo lover fix the issues with the encoding. I remember a discussion a while ago. > > Gabriel

Oct. 24, 2015

String>>#expandMacros new line macro rationale

by Gabriel Cotelli

Hi, yesterday I was playing with this method and found something awkward. <n> macro is expanded to CR. I was expecting that expands to the line ending of the platform, or at least to LF. Anybody knows if this have some explanation? I'm tempted to change the <n> expansion to use OSPlatform current lineEnding , and add <r> as a valid macro expanding to CR. I think it's more consistent with the general use. What do you think? If there's consensus I would create an issue and provide a Slice with the changes and some test cases. Gabriel

Oct. 23, 2015

Re: [Pharo-dev] [Vm-dev] Re: Random forest in Pharo

by Eliot Miranda

On Mon, Oct 19, 2015 at 11:05 PM, Ryan Macnak <rmacnak(a)gmail.com> wrote: > > On Mon, Oct 19, 2015 at 7:10 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> - a port of the Interpreter/Context VM to Spur >> > > What does the Context Interpreter do that the Stack Interpreter doesn't? I > thought 64-bit support was the last gap. > It is conceptually simpler. It supports experiments more easily than the StackInterpreter. It reflects the language specification in the blue book and the image-level meta-circular interpreter much more closely. _,,,^..^,,,_ best, Eliot

Oct. 23, 2015