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

Re: [Pharo-dev] Autonomous Shark-Monitoring Drone

by bsselfridge＠gmail.com

Here is Jon Hylands personal blog page Jon's Blog <http://blog.huv.com/> . He looks like a pretty intelligent electrical engineer and software developer. If interested, you might want to contact him to see if he would offer up his Smalltalk code for this project. Brad Selfridge ----- Brad Selfridge -- View this message in context: http://forum.world.st/Autonomous-Shark-Monitoring-Drone-tp4854226p4854435.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 8, 2015

Re: [Pharo-dev] Autonomous Shark-Monitoring Drone

by Marcus Denker

> On 08 Oct 2015, at 14:51, bsselfridge(a)gmail.com wrote: > > Eliot, > > Many years ago, I made the acquaintance of a fellow Smalltalker named Jon > Hylands. We was working on and gave a demonstration of an autonomous > underwater submarine that was written in Smalltalk then translated to > assembly. He showed us the Smalltalk code and logic seemed pretty > sophisticated and able to function similar to a RTOS. > > Here's a link, on Smalltalk.org for some of his work (not sure that he's > working on this anymore though): smalltalk.org-PICSmalltalk > <http://www.smalltalk.org/versions/PICSmalltalk.html> Indeedâ¦ that was amazing stuff. I never saw it live, but just from the pictures and descriptions this looked great. Marcus

Oct. 8, 2015

[pharo-project/pharo-core]

by GitHub

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

Oct. 8, 2015

[pharo-project/pharo-core] 84e732: 50373

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 84e73281ed25b425d9d9fb7358e46b5d086baa15 https://github.com/pharo-project/pharo-core/commit/84e73281ed25b425d9d9fb73… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-08 (Thu, 08 Oct 2015) Changed paths: M Nautilus.package/Nautilus.class/instance/accessing/packagesWithoutExtensions.st R NautilusCommon.package/extension/RBBrowserEnvironment/instance/packagesWithoutExtensions.st R NautilusCommon.package/extension/RBBrowserEnvironmentWrapper/instance/packagesWithoutExtensions.st R NautilusCommon.package/extension/RGClassDescriptionDefinition/instance/packagesWithoutExtensions.st R RPackage-Core.package/RPackageOrganizer.class/instance/accessing/packagesWithoutExtensions.st R RPackage-Core.package/extension/TClassDescription/instance/packagesWithoutExtensions.st A Refactoring-Critics.package/RBMultiEnvironment.class/instance/accessing/packages.st A Refactoring-Environment.package/RBAndEnvironment.class/instance/accessing/packages.st A Refactoring-Environment.package/RBAndEnvironment.class/instance/testing/classes.st A Refactoring-Environment.package/RBBrowserEnvironment.class/instance/accessing-packages/packagesWithContributors.st A Refactoring-Environment.package/RBBrowserEnvironment.class/instance/environments/withoutClasses_.st M Refactoring-Environment.package/RBBrowserEnvironmentWrapper.class/instance/accessing/packages.st A Refactoring-Environment.package/RBBrowserEnvironmentWrapper.class/instance/testing/includesPackage_.st A Refactoring-Environment.package/RBCategoryEnvironment.class/instance/accessing/packages.st A Refactoring-Environment.package/RBClassEnvironment.class/instance/accessing/packages.st A Refactoring-Environment.package/RBNotEnvironment.class/instance/accessing/packages.st M Refactoring-Environment.package/RBNotEnvironment.class/instance/testing/includesClass_.st A Refactoring-Environment.package/RBNotEnvironment.class/instance/testing/includesPackage_.st A Refactoring-Environment.package/RBOrEnvironment.class/instance/accessing/packages.st M Refactoring-Environment.package/RBPackageEnvironment.class/README.md A Refactoring-Environment.package/RBPackageEnvironment.class/instance/adding/addPackage_.st A Refactoring-Environment.package/RBPragmaEnvironment.class/instance/testing/packages.st A Refactoring-Environment.package/RBProtocolEnvironment.class/instance/testing/packages.st A Refactoring-Environment.package/RBVariableEnvironment.class/instance/accessing/packages.st M Refactoring-Tests-Environment.package/RBBrowserEnvironmentTest.class/instance/testing-environments/testAndEnvironment.st M Refactoring-Tests-Environment.package/RBBrowserEnvironmentTest.class/instance/testing-environments/testClassEnvironment.st M Refactoring-Tests-Environment.package/RBBrowserEnvironmentTest.class/instance/testing-environments/testNotEnvironment.st A Refactoring-Tests-Environment.package/RBBrowserEnvironmentTest.class/instance/testing-environments/testNotEnvironmentWithClassEnvironments.st M Refactoring-Tests-Environment.package/RBBrowserEnvironmentTest.class/instance/testing-environments/testOrEnvironment.st A Refactoring-Tests-Environment.package/RBBrowserEnvironmentTest.class/instance/testing/testWithoutClassesRemovesClassesFromSender.st M Reflectivity.package/ReflectiveMethod.class/definition.st M Reflectivity.package/ReflectiveMethod.class/instance/accessing/compiledMethod_.st M Reflectivity.package/ReflectiveMethod.class/instance/invalidate/installCompiledMethod.st M Rubric.package/RubSmalltalkEditor.class/instance/menu messages/selectedSelector.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50372.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50373.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50372.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50373.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Text-Edition.package/SmalltalkEditor.class/instance/menu messages/selectedSelector.st Log Message: ----------- 50373 16628 RBBrowseEnvironment doesnt respect the Set Theory https://pharo.fogbugz.com/f/cases/16628 16739 Senders and implementors do not work when one parameter is a selector in the form "with:do" (no space) https://pharo.fogbugz.com/f/cases/16739 16745 ReflectiveMethod: do not get class from AST https://pharo.fogbugz.com/f/cases/16745 http://files.pharo.org/image/50/50373.zip

Oct. 8, 2015

Re: [Pharo-dev] Autonomous Shark-Monitoring Drone

by bsselfridge＠gmail.com

Eliot, Many years ago, I made the acquaintance of a fellow Smalltalker named Jon Hylands. We was working on and gave a demonstration of an autonomous underwater submarine that was written in Smalltalk then translated to assembly. He showed us the Smalltalk code and logic seemed pretty sophisticated and able to function similar to a RTOS. Here's a link, on Smalltalk.org for some of his work (not sure that he's working on this anymore though): smalltalk.org-PICSmalltalk <http://www.smalltalk.org/versions/PICSmalltalk.html> Brad Selfridge ----- Brad Selfridge -- View this message in context: http://forum.world.st/Autonomous-Shark-Monitoring-Drone-tp4854226p4854410.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 8, 2015

Re: [Pharo-dev] [ Zn+Zdc ] Implementation of HTTPS proxying using HTTP CONNECT tunneling

by Damien Cassou

Sven Van Caekenberghe <sven(a)stfx.eu> writes: > Yesterday I did a first implementation of HTTPS proxying using HTTP > CONNECT tunneling for Zn+Zdc, this should now be tested by a wider > audience. With this new feature it should now be possible to access > HTTPS Urls from behind an HTTP proxy. This is for all OS platforms. > Thanks Nicolai for finding the spec reference and Torsten for the > push. I have no use for that but I think this goes in the right direction. Thank you very much! -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Oct. 8, 2015

Re: [Pharo-dev] [OT] Slides the web way

by Damien Cassou

Esteban A. Maringolo <emaringolo(a)gmail.com> writes: > I used reveal.js vÃa Slides.com for a demo [1] > > It's produces really nice presentations. could you please give us the sources? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Oct. 8, 2015

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

by Marco Naddeo

Hi Henrik, thank you but my problem is not that particular block, but rather the fact that I need to navigate the AST of *any* block (no matter which one and how much is big) to retrieve the last statement in it... Anyhow, for the moment I can use your refactoring to make my tests succeed. ;-) So thanks. Marco Il 07/10/2015 18:05, Henrik Nergaard ha scritto: > Hi Marco, > > Had some fun with the code you posted :D. > This *should* be the equivalent, but with less variables so that you can access the RBBlockNode. > > [ :h :s :v | | chroma rgb | > chroma := s*v. > rgb := { 0 . 0 . 0 }. > rgb > at: ((((h + 60) // 120) \\ 3) + 1) put: chroma; > at: ((((h // 60) + 2 \\ 3) * 5 \\ 3) + 1) put: (chroma * (1.0 - (((h/60) \\ 2) - 1.0) abs)); > collect: [ :part | (part + (v - (chroma) )) * 255 ] > ] sourceNode . > > > Best Regards, > Henrik > > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Marco Naddeo > Sent: Wednesday, October 7, 2015 3:49 PM > To: Pharo-dev <pharo-dev(a)lists.pharo.org> > Subject: [Pharo-dev] Problems with a large block > > Hi, > > I have some problems with the large block at bottom: > > -sending the message argumentNames gives me an empty array #() -sending the message sourceNode gives me a strange result and not a RBBlockNode, as I would expect > > Best, > Marco > > > > [ :h :s :v | > | min chroma hdash X red green blue | > red := 0. > green:= 0. > blue := 0. > chroma := s * v. > hdash := h / 60. > X := chroma * (1.0 - ((hdash % 2) - 1.0) abs). > (hdash < 1.0) > ifTrue: [ red := chroma. > green := X ] > ifFalse: [ > (hdash < 2.0) > ifTrue: [ red := X. > green := chroma ] > ifFalse: [ > (hdash < 3.0) > ifTrue: [ green := chroma. > blue := X ] > ifFalse: [ > (hdash < 4.0) > ifTrue: [ green := X. > blue := chroma ] > ifFalse: [ > (hdash < 5.0) > ifTrue: [ red := X. > blue := chroma ] > ifFalse: [ > (hdash <= 6.0) > ifTrue: [ red := chroma. > blue := X ] > ] > ] > ] > ] > ]. > min := v - chroma. > { #red -> ((red + min) * 255). > #green -> ((green + min) * 255). > #blue -> ((blue + min) * 255) } ] > > > > -- > Marco Naddeo > > PhD Student > Dipartimento di Informatica > UniversitÃ degli Studi di Torino > Corso Svizzera 185, 10149 Torino, Italy > > > -- Marco Naddeo PhD Student Dipartimento di Informatica UniversitÃ degli Studi di Torino Corso Svizzera 185, 10149 Torino, Italy

Oct. 8, 2015

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

by Nicolai Hess

2015-10-08 9:39 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolai, > > On Thu, Oct 8, 2015 at 12:09 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> >> >> 2015-10-08 1:30 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> Hi Nicolai, >>> >>> On Wed, Oct 7, 2015 at 2:13 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >>> >>>> >>>> >>>> 2015-10-07 16:49 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: >>>> >>>>> >>>>> > On 07 Oct 2015, at 15:49, Marco Naddeo <naddeo(a)di.unito.it> wrote: >>>>> > >>>>> > Hi, >>>>> > >>>>> > I have some problems with the large block at bottom: >>>>> > >>>>> > -sending the message argumentNames gives me an empty array #() >>>>> > -sending the message sourceNode gives me a strange result and not a >>>>> RBBlockNode, as I would expect >>>>> > >>>>> >>>>> This happens already with: >>>>> >>>>> [ :h :s :v | | min chroma hdash X red green blue | ] sourceNode >>>>> >>>>> I will checkâ¦ it is a bug in the mapping pc -> AST. >>>>> >>>> >>>> That's interesting, the way the pc is mapped to the AST (ir >>>> instructionForPC: ) >>>> takes the "length" of the instruction bytecode into account and the >>>> length of a pushclosure includes >>>> all bytes needed for the pushing the local temps (pushConstant nil. >>>> pushConstant nil ....) >>>> >>>> But the startPC of a block context starts at the first push, not after, >>>> that means >>>> >>>> self method sourceNodeForPC: self startpc - 1 >>>> starts the search after the push closure bytecode but before any push >>>> local temp byte code. >>>> >>>> Either we don't include the bytecodes for the "pushConstant:nil" in the >>>> bytecode offset, or we start the search at >>>> >>>> self method sourceNodeForPC: self startpc - 1 + self numLocalTemps >>>> >>> >>> No, no, no, no, no :-). >>> >> >> I think I will always get confused by BlockClosure code at the bytecode >> level :) >> > > What exactly do you find confusing? > For a moment, I was unsure in which context the pushConstant:nil are executed, on construction or when executing the block. > The byte codes are simple if you read the right source. Perhaps you could > talk with ClÃ©ment; he's local and understands the byte code set as well as > I do. If you can't talk to him you could read the class comment of > EncoderForV3PlusClosures in a Squeak 4.6 or 5.0 image, or the class comment > of EncoderForSistaV1 in the BytecodeSets package on > http://source.squeak.org/VMMaker. > > If you're confused by the scheme for closing over variables have you read > my blog posts on the closure compiler? > Yes I read your blog and it is a great source of information, not only about the current state and what is new, but even about the history of the smalltalk vm - this is always good to know. > > I wish you hadn't deleted this bit, it is "the truth": > I didn't want to hide "the truth" :) I thought this was the same I wrote and understand, the startPC starts at the first pushConstant:nil for creating space, for the local temp, on the stack. > > "*The PC in question is the pc of the block creation byte code. The > startpc of a block is the first bytecode following the block creation byte > code. That *includes* any pushConstant: nil byte codes establishing temps > in the block. Instead, it is expected that "self method sourceNodeForPC: > self startpc - 1" answers the same as "self method sourceNodeForPC: self > blockCreationPC", where self blockCreationPC is the pc of the block's block > creation bytecode.* > > *In Squeak we have* > *BlockClosure>>blockCreationPC* > * "Answer the pc for the bytecode that created the receuver."* > * | method |* > * method := self method.* > * ^method encoderClass* > * pcOfBlockCreationBytecodeForBlockStartingAt: startpc* > * in: method* > > *This is because we support (as you will soon enough) different byte code > sets so it is wrong to assume the size of the block creation bytecode is 4.* > " > > >> >>> >>> self method sourceNodeForPC: self startpc - 4 >>> >> >> We already have this little heuristic >> >> instructionForPC: aPC >> 0 to: -3 by: -1 do: [ :off | >> (self firstInstructionMatching: [:ir | ir bytecodeOffset = (aPC - >> off) ]) ifNotNil: [:it |^it]] >> >> AFAUI this 0 to -3 offset is used because we have 1,2,3 or 4 byte-length >> bytecodes. >> > > Well this will break down with the Sista byte code > I did not write that code, I just try to understand what I see. > set because one could conceivably have 7 or 8 byte bytecoedes when one > includes prefixes. In the Newspeak and Sista sets we extend the ranges of > byte codes by allowing prefixes. Notionally the number of prefixes is > unlimited but in practice we're using only one of each of the two prefix > bytecodes Prefix A & Prefix B (currently E0 and E1 in all sets). > > But in the Sista set there is a field in the block creation byte code that > reveals how many prefixes the byte code has so one can compute the actual > start of the block creation byte code. i.e. > > EncoderForSistaV1 class>>pcOfBlockCreationBytecodeForBlockStartingAt: > startpc in: method > "Answer the pc of the push closure bytecode whose block starts at startpc > in method. > May need to back up to include extension bytecodes." > > "* 224 11100000 aaaaaaaa Extend A (Ext A = Ext A prev * 256 + Ext A) > * 225 11100001 bbbbbbbb Extend B (Ext B = Ext B prev * 256 + Ext B) > ** 250 11111010 eeiiikkk jjjjjjjj Push Closure Num Copied iii > (+ExtA//16*8) Num Args kkk (+ ExtA\\16*8) BlockSize jjjjjjjj (+ExtB*256). > ee = num extensions" > | numExtensions | > self assert: (method at: startpc - 3) = 250. > numExtensions := (method at: startpc - 2) >> 6. > ^startpc - 3 - (numExtensions * 2) > > and make sure that the compiler maps a block creation bytecode to the >>> source node for the entire block. >>> >> >> in the above code (instructionForPC) we try to find the instruction for >> the pc (here the pc of the closure creation code), but I don't really >> understand what >> "bytecodeOffset" is, it looks like (bytecodeIndex+startPC), but for a >> IRPushClosureCopy, it looks like the bytecodeIndex does include >> the number of local temps resp. (numberOfLocalTemps times the >> bytecodelength for pushConstant:nil). >> > > Marcus, what is bytecodeOffset? Is it the distance from the first byte > code or the distance from the first literal or...? > > The way to think about "self method sourceNodeForPC: self startpc - 1 + >>> self numLocalTemps" not making sense is that a pc inside the block must map >>> to a statement inside the block, not the block itself. >>> >> >> Hm, I don't know :) >> > > Why? I designed the closure byte code set so I'm telling you :-). It's > safe to believe me. > I do believe, I just don't understand. > For example, an initial pushConstant: nil byte code in a block either > establishes the first local temp in that block, or is an argument of a send > in the block. In either case it refers to an element inside the block, not > to the entire block itself. the thing that defines the entire block is the > block creation byte code, which includes the span (the size of) the block's > bytecodes. I chose to live with this annoying ambiguity because there were > very few unused byte codes and I did;t want to use all of them for the > closure byte code set. And I chose the closure architecture so I could > write a faster VM than one that accessed temps directly in outer scopes > (which I go into at length on my blog). > I read it, but I don't understand how can calling self method sourceNodeForPC: self startpc -1 depend on the pc inside the block? Isn't this only to get the sourceNode of the block object? > > HTH >>> >>> >>>> >>>> >>>>> >>>>> Marcus >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot >>> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

Oct. 8, 2015

Re: [Pharo-dev] [issue tracker] 6 issue fixed in external package, needs to be pushed into pharo

by Andrei Chis

Will make an issue later today for gtools. On Thu, Oct 8, 2015 at 9:08 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Re-Ping. Now we have 7 issues waiting. > > > On 05 Oct 2015, at 08:04, marcus.denker(a)inria.fr wrote: > > > > Hello Maintainers of externally managed packages, > > > > We have 6 cases that need your action to get the fix (which is fixed in > the repo of the package) > > back into Pharo. > > > > I made a new filter so these cases are easy to find: > > > > https://pharo.fogbugz.com/f/filters/138/fixed-upstream > > > > Keep in mind that it is better to merge back sooner than later, > especially trivialities. > > > > Marcus > > >

Oct. 8, 2015