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

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

by Marcus Denker

Now 8. > On 08 Oct 2015, at 09:08, 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

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

by Eliot Miranda

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? 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? I wish you hadn't deleted this bit, it is "the truth": "*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 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. 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). HTH >> >> >>> >>> >>>> >>>> Marcus >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> > > -- _,,,^..^,,,_ best, Eliot

Oct. 8, 2015

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

by Nicolai Hess

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 :) > > 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. > > 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). > > The way to think about "self method sourceNodeForPC: self startpc - 1 + > self numLocalTemps" not masking 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 :) > HTH > > >> >> >>> >>> Marcus >>> >>> >>> >>> >>> >>> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

Oct. 8, 2015

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

by Marcus Denker

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

[pharo-project/pharo-core] 0c9b32: 50372

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 0c9b32f314e4f089a8c054e7856b3946c996a81e https://github.com/pharo-project/pharo-core/commit/0c9b32f314e4f089a8c054e7… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-08 (Thu, 08 Oct 2015) Changed paths: M Collections-Strings.package/String.class/instance/accessing/includesSubstring_.st M Nautilus-Tests.package/NautilusUITest.class/instance/initialization/setUp.st M Reflectivity.package/ReflectiveMethod.class/instance/evaluation/compileAndInstallCompiledMethod.st M Reflectivity.package/ReflectiveMethod.class/instance/evaluation/run_with_in_.st M ScriptLoader50.package/ScriptLoader.class/instance/accessing/diffServerRootString.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50371.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50372.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50371.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50372.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M SmartSuggestions-Tests.package/SugsContextTest.class/instance/valid-context/testContextForNautilusItsANautilusContext.st Log Message: ----------- 50372 16737 fix all users of NautilusUI https://pharo.fogbugz.com/f/cases/16737 12354 includesSubstring: should return true when the argument is empty https://pharo.fogbugz.com/f/cases/12354 16738 Reflectivity: do not wrap primitives if there is no link https://pharo.fogbugz.com/f/cases/16738 16418 ScriptLoader>>diffServerRootString with Pharo 3 repo for Pharo 5? https://pharo.fogbugz.com/f/cases/16418 http://files.pharo.org/image/50/50372.zip

Oct. 8, 2015

[pharo-project/pharo-core]

by GitHub

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

Oct. 8, 2015

Fun fact with FastTable...

by Thierry Goubier

FTTableContainerMorph>>drawOn: is called more than once (more than twice?) in quick succession (for every display request?). So the whole rowSubviews loop is done multiple times for no reason, since the first one is already correct. Thierry

Oct. 8, 2015

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

by David T. Lewis

Sounds like an interesting and worthwhile thing to do. I'm not sure how much I can contribute, but if it turns out that there is a need for any VM plugins and/or OSProcess glue to make the thing work, I will happily volunteer for that. I don't mind buying some hardware (Rasperry Pi?) to work with, although that rubber shark may be a bit beyond my budget. Seriously, this is a good idea and it would be a lot of fun if we could make it work. Dave On Wed, Oct 07, 2015 at 08:54:55AM -0700, Eliot Miranda wrote: > Dear Friends and Colleagues, > > as you may know, Sharks, as apex predators, are vital to maintaining > healthy marine ecosystems, and at the same time, their populations are > plummeting due to human actions. It is estimated for example that the > population of pelagic oceanic white tip sharks is reducing by 17% per year > [1] and I've heard (can't find a reference) that populations in the eastern > indian/western pacific are at 1% of normal levels. Such reductions in > populations create "trophic cascades" that produce wide-ranging changes in > populations of different species all the way down the food chain [2]. And > the marine ecosystem is a key source of human nutrition; it comprises > between 13% and 17% of global human protein intake [3]. > > As you may also know, there is currently a shark attack crisis in New > South Wales [4]. While most people in the region oppose killing sharks in > response to the crisis, existing solutions, netting and culling reduce > those same threatened populations of sharks upon which the sustainability > of marine food supply d ecosystems depend [5], and are arguably ineffective > [6]. Apparently the most successful approach at avoiding attacks is the > use of human spotters, as used in Cape Town, where people in tall towers > scan the sea close to shore [6]. > > But please watch this Youtube video > <https://www.youtube.com/watch?v=q2U3gjwJfS4> [7] from Pismo Beach, > California. The shark is spotted at about 1:20 into the video. This > drone, a phantom 3, is sending live video back to the operators, who are > using remote control. What we can see from this video is that the point of > view of drones is far superior to that of spotters. > > My first thought is that autonomous drones could provide a cheap and > scalable solution to patrolling beaches to prevent shark attacks. I expect > that processors like the Pi 2 have easily enough processing power to both > plan and execute search patterns along beaches, and perform the image > recognition necessary to reliably detect potentially dangerous sharks. A > drone might also be able autonomously to visit surfers and swimmers near to > the shark and warn them, either by some signal such as flashing red LEDs or > an audible message (language issues notwithstanding). The drone would have > to be able to identify swimmers and surfers in the water (not easy; sharks > confuse seals and surfers all the time), but computing an optimal route to > visit suspected swimmers should be relatively easy :-). > > I imagine that sooner or later it will be possible to construct cheap > rugged solar powered docking/charging shelters that drones could depart > from and return to, to charge and shelter from the elements after patrols. > Satellite communications could provide status reports for maintenance. > > My second thought is that as a community, we probably have all the > necessary expertise to construct a working prototype that at least > demonstrates feasibility. Such a prototype would have to be able to fly > above the ocean along a beach under its own control for a useful period of > time, at least 15 minutes, and demonstrate that it can identify a shark in > the water (we could use a rubber shark > <https://www.youtube.com/watch?v=9dghbyBaQyI> for testing ;-) ). > > Our community includes people doing image recognition with the Pi, radio > control experts, users of 3D printers, and some exceptional programmers. > If a small, strong group could be formed with the relevant expertise we may > be able to develop a prototype in a short enough time frame to be > relevant. Of course, availability of time is a big issue. I couldn't > contribute more than a few hours a week. But nothing ventured, nothing > gained. So I'm writing this message to the Squeak and Pharo communities, > and bcc'ing a few friends I know that have relevant expertise to ask for > two things; first, for good information on scoping out the project, > possible technologies, power budgets, costs, what is available > off-the-shelf (both in hardware and known algorithms) and what we would > need to construct ourselves, and second, for volunteers. Who among us are > really excited by this project, have relevant expertise and are motivated > to make a contribution? > > > [1] www.sharkadvocates.org/cites_4sharks_owt_fact_sheet.pdf > [2] http://www.globalshark.ca/pressmaterial/cascading/fig1_web.pdf > [3] http://www.who.int/nutrition/topics/3_foodconsumption/en/index5.html > [4] http://www.bbc.com/news/world-australia-34398516 > [5] > http://www.theguardian.com/environment/2015/sep/29/shark-hit-australian-com… > [6] http://www.nonswsharkcull.net/latestnews/tag/shark_spotting/ > [7] https://www.youtube.com/watch?v=q2U3gjwJfS4 > > > > crazier ideas: > > Infra red cameras are becoming cheap and easily available. Species like > Great White and Bull Shark have elevated metabolisms, effectively they are > warm blooded, so these two facts may allow spotting at night. > > Sharks are extremely sensitive to electrical fields; maybe some kind of > transmitter could be fitted to a drone, e.g. via a wire suspended in the > water, that could generate a field that could direct the shark away from > swimmers > > _,,,^..^,,,_ > best, Eliot >

Oct. 8, 2015

[ANN]: Magritte: Extensible Reference Description Morph

by Sean P. DeNigris

For those not following the Magritte list. I scratched an itch I've been feeling for a long time using Magritte... Full details at https://github.com/magritte-metamodel/magritte/issues/28 There was not a viable control for the use case where you are choosing between several likely known options, but may also select an unknown object that was not part of the initial options. For example, when tagging people in a photos, you'd want to start with known people, but be able to add new people too. Here's a screencast: https://www.youtube.com/watch?v=dV9_Z12G2Y0 NB the completion menu appears in a seemingly random place. I guess this is a Pharo bug, but I'm currently only using the morph internally so I can live with it ----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-Magritte-Extensible-Reference-Description-Morph-t… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 8, 2015

Re: [Pharo-dev] [ANN]: AconcaguaAddOns

by Sean P. DeNigris

stepharo wrote > welcome back. Thanks! You guys have been busy :) I've given up on trying to go back through all the mail I missed... ----- Cheers, Sean -- View this message in context: http://forum.world.st/ANN-AconcaguaAddOns-tp4820940p4854309.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 8, 2015

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

by Eliot Miranda

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 :-). 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. But for now you could use self method sourceNodeForPC: self startpc - 4 and make sure that the compiler maps a block creation bytecode to the source node for the entire block. The way to think about "self method sourceNodeForPC: self startpc - 1 + self numLocalTemps" not masking sense is that a pc inside the block must map to a statement inside the block, not the block itself. HTH > > >> >> Marcus >> >> >> >> >> >> > -- _,,,^..^,,,_ best, Eliot

Oct. 7, 2015

Re: [Pharo-dev] Issue Tracker Choice

by Alexandre Bergel

It would be interesting indeed. However, I value much more an integration with git. Alexandre > Le 7 oct. 2015 Ã 03:27, Eliot Miranda <eliot.miranda(a)gmail.com> a Ã©crit : > > >> On Oct 6, 2015, at 8:30 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Damien Cassou-2 wrote >>> could you please tell us what you don't like about FogBugz >> >> The main thing is that it's not designed for open source projects. Requiring >> account creation before one can even search the open issues is a huge >> barrier. I would guess most new people will hit that wall and give up on >> sending us valuable bug reports. > > > +1. > > BTW, at ParcPlace we implemented our own. It's not difficult and having something one can tailor is great. Pharo has the relevant web, database & server technology. It would be a great test of the system to implement its own issue tracker. > > > _,,,^..^,,,_ (phone) > >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Issue-Tracker-Choice-tp4854002p4854106.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 7, 2015

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

by phil＠highoctane.be

And maybe some Grafoscopio On Wed, Oct 7, 2015 at 10:09 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > As we have: > > - Pillar to write content in wiki syntax and generate HTML out of it > - Mustache as template engine > - Teapot to easily server static and dynamic web content > > one might create his next Pharo presentations in HTML5 easily: > > http://impress.github.io/impress.js > https://code.google.com/p/io-2012-slides > http://lab.hakim.se/reveal-js/#/ > > and serve it from Pharo > > > > >

Oct. 7, 2015

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

by Nicolai Hess

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 > > Marcus > > > > > >

Oct. 7, 2015

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

by Ferlicot D. Cyril

Le 07/10/2015 22:09, Torsten Bergmann a Ã©crit : > As we have: > > - Pillar to write content in wiki syntax and generate HTML out of it > - Mustache as template engine > - Teapot to easily server static and dynamic web content > > one might create his next Pharo presentations in HTML5 easily: > > http://impress.github.io/impress.js > https://code.google.com/p/io-2012-slides > http://lab.hakim.se/reveal-js/#/ > > and serve it from Pharo > > > > Hi, You can generate Deck.js presentations with Pillar :) You can see an example with PharoMooc slides[1][2]. (We just need to create a better css and some little adjustments! ) And you can also generate Beamer with the same Pillar file. [1] https://github.com/SquareBracketAssociates/PharoMooc [2] https://ci.inria.fr/pharo-contribution/view/Books/job/PharoMooc/ws/book-res… -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Oct. 7, 2015

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

by Esteban A. Maringolo

I used reveal.js vÃa Slides.com for a demo [1] It's produces really nice presentations. Esteban A. Maringolo [1] http://slides.com/emaringolo/oop-smalltalk-back-to-the-future#/ 2015-10-07 17:09 GMT-03:00 Torsten Bergmann <astares(a)gmx.de>: > As we have: > > - Pillar to write content in wiki syntax and generate HTML out of it > - Mustache as template engine > - Teapot to easily server static and dynamic web content > > one might create his next Pharo presentations in HTML5 easily: > > http://impress.github.io/impress.js > https://code.google.com/p/io-2012-slides > http://lab.hakim.se/reveal-js/#/ > > and serve it from Pharo > > > >

Oct. 7, 2015

[OT] Slides the web way

by Torsten Bergmann

As we have: - Pillar to write content in wiki syntax and generate HTML out of it - Mustache as template engine - Teapot to easily server static and dynamic web content one might create his next Pharo presentations in HTML5 easily: http://impress.github.io/impress.js https://code.google.com/p/io-2012-slides http://lab.hakim.se/reveal-js/#/ and serve it from Pharo

Oct. 7, 2015

Re: [Pharo-dev] [ANN] Pharo Catalog web page updated

by Thierry Goubier

Le 07/10/2015 19:17, Esteban Lorenzano a Ã©crit : > Hi, > > I spend some time today adding some functionality top the Pharo > Catalog web page. Is still far from *good* but I think now is a lot > better: > > http://catalog.pharo.org Certainly better :) Thierry > Enjoy, Esteban > > ps: as a âhistoryâ note, Pharo Catalog page was never intended to > last too much, it was going to be replaced for a complete web-page, > and it still will be, but since is not ready and I donât know when it > will be, I think is better to enhance the current one :) > > >

Oct. 7, 2015

Re: [Pharo-dev] [ANN] Pharo Catalog web page updated

by zio su gmail

Thanks Esteban, it's nice :-) Pietro > Hi, > > I spend some time today adding some functionality top the Pharo Catalog web page. > Is still far from *good* but I think now is a lot better: > > http://catalog.pharo.org > > Enjoy, > Esteban > > ps: as a âhistoryâ note, Pharo Catalog page was never intended to last too much, it was going to be replaced for a complete web-page, and it still will be, but since is not ready and I donât know when it will be, I think is better to enhance the current one :) > > > . >

Oct. 7, 2015

Re: [Pharo-dev] [ANN] Pharo Catalog web page updated

by Esteban Lorenzano

btwâ¦ this remembers me that there are A LOT of packages without correct catalog information. I beg project owners to update your configurationsâ¦ a non-findable project is as good as non existent :( Esteban > On 07 Oct 2015, at 19:17, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > I spend some time today adding some functionality top the Pharo Catalog web page. > Is still far from *good* but I think now is a lot better: > > http://catalog.pharo.org > > Enjoy, > Esteban > > ps: as a âhistoryâ note, Pharo Catalog page was never intended to last too much, it was going to be replaced for a complete web-page, and it still will be, but since is not ready and I donât know when it will be, I think is better to enhance the current one :) >

Oct. 7, 2015

Re: [Pharo-dev] [ANN] Pharo Catalog web page updated

by Yuriy Tymchuk

Looks nice(er)! Thanks Esteban. Uko > On 07 Oct 2015, at 19:17, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > I spend some time today adding some functionality top the Pharo Catalog web page. > Is still far from *good* but I think now is a lot better: > > http://catalog.pharo.org > > Enjoy, > Esteban > > ps: as a âhistoryâ note, Pharo Catalog page was never intended to last too much, it was going to be replaced for a complete web-page, and it still will be, but since is not ready and I donât know when it will be, I think is better to enhance the current one :) > >

Oct. 7, 2015

[ANN] Pharo Catalog web page updated

by Esteban Lorenzano

Hi, I spend some time today adding some functionality top the Pharo Catalog web page. Is still far from *good* but I think now is a lot better: http://catalog.pharo.org Enjoy, Esteban ps: as a âhistoryâ note, Pharo Catalog page was never intended to last too much, it was going to be replaced for a complete web-page, and it still will be, but since is not ready and I donât know when it will be, I think is better to enhance the current one :)

Oct. 7, 2015

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

by philippe.back＠highoctane.be

Maybe you want to connect with the people at Fleye. Their drone is quite close to what you have in mind. Le 7 oct. 2015 17:55, "Eliot Miranda" <eliot.miranda(a)gmail.com> a Ã©crit : > Dear Friends and Colleagues, > > as you may know, Sharks, as apex predators, are vital to maintaining > healthy marine ecosystems, and at the same time, their populations are > plummeting due to human actions. It is estimated for example that the > population of pelagic oceanic white tip sharks is reducing by 17% per year > [1] and I've heard (can't find a reference) that populations in the eastern > indian/western pacific are at 1% of normal levels. Such reductions in > populations create "trophic cascades" that produce wide-ranging changes in > populations of different species all the way down the food chain [2]. And > the marine ecosystem is a key source of human nutrition; it comprises > between 13% and 17% of global human protein intake [3]. > > As you may also know, there is currently a shark attack crisis in New > South Wales [4]. While most people in the region oppose killing sharks in > response to the crisis, existing solutions, netting and culling reduce > those same threatened populations of sharks upon which the sustainability > of marine food supply d ecosystems depend [5], and are arguably ineffective > [6]. Apparently the most successful approach at avoiding attacks is the > use of human spotters, as used in Cape Town, where people in tall towers > scan the sea close to shore [6]. > > But please watch this Youtube video > <https://www.youtube.com/watch?v=q2U3gjwJfS4> [7] from Pismo Beach, > California. The shark is spotted at about 1:20 into the video. This > drone, a phantom 3, is sending live video back to the operators, who are > using remote control. What we can see from this video is that the point of > view of drones is far superior to that of spotters. > > My first thought is that autonomous drones could provide a cheap and > scalable solution to patrolling beaches to prevent shark attacks. I expect > that processors like the Pi 2 have easily enough processing power to both > plan and execute search patterns along beaches, and perform the image > recognition necessary to reliably detect potentially dangerous sharks. A > drone might also be able autonomously to visit surfers and swimmers near to > the shark and warn them, either by some signal such as flashing red LEDs or > an audible message (language issues notwithstanding). The drone would have > to be able to identify swimmers and surfers in the water (not easy; sharks > confuse seals and surfers all the time), but computing an optimal route to > visit suspected swimmers should be relatively easy :-). > > I imagine that sooner or later it will be possible to construct cheap > rugged solar powered docking/charging shelters that drones could depart > from and return to, to charge and shelter from the elements after patrols. > Satellite communications could provide status reports for maintenance. > > My second thought is that as a community, we probably have all the > necessary expertise to construct a working prototype that at least > demonstrates feasibility. Such a prototype would have to be able to fly > above the ocean along a beach under its own control for a useful period of > time, at least 15 minutes, and demonstrate that it can identify a shark in > the water (we could use a rubber shark > <https://www.youtube.com/watch?v=9dghbyBaQyI> for testing ;-) ). > > Our community includes people doing image recognition with the Pi, radio > control experts, users of 3D printers, and some exceptional programmers. > If a small, strong group could be formed with the relevant expertise we may > be able to develop a prototype in a short enough time frame to be > relevant. Of course, availability of time is a big issue. I couldn't > contribute more than a few hours a week. But nothing ventured, nothing > gained. So I'm writing this message to the Squeak and Pharo communities, > and bcc'ing a few friends I know that have relevant expertise to ask for > two things; first, for good information on scoping out the project, > possible technologies, power budgets, costs, what is available > off-the-shelf (both in hardware and known algorithms) and what we would > need to construct ourselves, and second, for volunteers. Who among us are > really excited by this project, have relevant expertise and are motivated > to make a contribution? > > > [1] www.sharkadvocates.org/cites_4sharks_owt_fact_sheet.pdf > [2] http://www.globalshark.ca/pressmaterial/cascading/fig1_web.pdf > [3] http://www.who.int/nutrition/topics/3_foodconsumption/en/index5.html > [4] http://www.bbc.com/news/world-australia-34398516 > [5] > http://www.theguardian.com/environment/2015/sep/29/shark-hit-australian-com… > [6] http://www.nonswsharkcull.net/latestnews/tag/shark_spotting/ > [7] https://www.youtube.com/watch?v=q2U3gjwJfS4 > > > > crazier ideas: > > Infra red cameras are becoming cheap and easily available. Species like > Great White and Bull Shark have elevated metabolisms, effectively they are > warm blooded, so these two facts may allow spotting at night. > > Sharks are extremely sensitive to electrical fields; maybe some kind of > transmitter could be fitted to a drone, e.g. via a wire suspended in the > water, that could generate a field that could direct the shark away from > swimmers > > _,,,^..^,,,_ > best, Eliot >

Oct. 7, 2015

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

by Henrik Nergaard

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

Oct. 7, 2015

Autonomous Shark-Monitoring Drone

by Eliot Miranda

Dear Friends and Colleagues, as you may know, Sharks, as apex predators, are vital to maintaining healthy marine ecosystems, and at the same time, their populations are plummeting due to human actions. It is estimated for example that the population of pelagic oceanic white tip sharks is reducing by 17% per year [1] and I've heard (can't find a reference) that populations in the eastern indian/western pacific are at 1% of normal levels. Such reductions in populations create "trophic cascades" that produce wide-ranging changes in populations of different species all the way down the food chain [2]. And the marine ecosystem is a key source of human nutrition; it comprises between 13% and 17% of global human protein intake [3]. As you may also know, there is currently a shark attack crisis in New South Wales [4]. While most people in the region oppose killing sharks in response to the crisis, existing solutions, netting and culling reduce those same threatened populations of sharks upon which the sustainability of marine food supply d ecosystems depend [5], and are arguably ineffective [6]. Apparently the most successful approach at avoiding attacks is the use of human spotters, as used in Cape Town, where people in tall towers scan the sea close to shore [6]. But please watch this Youtube video <https://www.youtube.com/watch?v=q2U3gjwJfS4> [7] from Pismo Beach, California. The shark is spotted at about 1:20 into the video. This drone, a phantom 3, is sending live video back to the operators, who are using remote control. What we can see from this video is that the point of view of drones is far superior to that of spotters. My first thought is that autonomous drones could provide a cheap and scalable solution to patrolling beaches to prevent shark attacks. I expect that processors like the Pi 2 have easily enough processing power to both plan and execute search patterns along beaches, and perform the image recognition necessary to reliably detect potentially dangerous sharks. A drone might also be able autonomously to visit surfers and swimmers near to the shark and warn them, either by some signal such as flashing red LEDs or an audible message (language issues notwithstanding). The drone would have to be able to identify swimmers and surfers in the water (not easy; sharks confuse seals and surfers all the time), but computing an optimal route to visit suspected swimmers should be relatively easy :-). I imagine that sooner or later it will be possible to construct cheap rugged solar powered docking/charging shelters that drones could depart from and return to, to charge and shelter from the elements after patrols. Satellite communications could provide status reports for maintenance. My second thought is that as a community, we probably have all the necessary expertise to construct a working prototype that at least demonstrates feasibility. Such a prototype would have to be able to fly above the ocean along a beach under its own control for a useful period of time, at least 15 minutes, and demonstrate that it can identify a shark in the water (we could use a rubber shark <https://www.youtube.com/watch?v=9dghbyBaQyI> for testing ;-) ). Our community includes people doing image recognition with the Pi, radio control experts, users of 3D printers, and some exceptional programmers. If a small, strong group could be formed with the relevant expertise we may be able to develop a prototype in a short enough time frame to be relevant. Of course, availability of time is a big issue. I couldn't contribute more than a few hours a week. But nothing ventured, nothing gained. So I'm writing this message to the Squeak and Pharo communities, and bcc'ing a few friends I know that have relevant expertise to ask for two things; first, for good information on scoping out the project, possible technologies, power budgets, costs, what is available off-the-shelf (both in hardware and known algorithms) and what we would need to construct ourselves, and second, for volunteers. Who among us are really excited by this project, have relevant expertise and are motivated to make a contribution? [1] www.sharkadvocates.org/cites_4sharks_owt_fact_sheet.pdf [2] http://www.globalshark.ca/pressmaterial/cascading/fig1_web.pdf [3] http://www.who.int/nutrition/topics/3_foodconsumption/en/index5.html [4] http://www.bbc.com/news/world-australia-34398516 [5] http://www.theguardian.com/environment/2015/sep/29/shark-hit-australian-com… [6] http://www.nonswsharkcull.net/latestnews/tag/shark_spotting/ [7] https://www.youtube.com/watch?v=q2U3gjwJfS4 crazier ideas: Infra red cameras are becoming cheap and easily available. Species like Great White and Bull Shark have elevated metabolisms, effectively they are warm blooded, so these two facts may allow spotting at night. Sharks are extremely sensitive to electrical fields; maybe some kind of transmitter could be fitted to a drone, e.g. via a wire suspended in the water, that could generate a field that could direct the shark away from swimmers _,,,^..^,,,_ best, Eliot

Oct. 7, 2015

Re: [Pharo-dev] Smalltalkhub instable

by Blondeau Vincent

Thanks Marcus Vincent De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Marcus Denker EnvoyÃ© : mercredi 7 octobre 2015 16:56 Ã : Pharo Development List Objet : Re: [Pharo-dev] Smalltalkhub instable On 07 Oct 2015, at 15:47, Blondeau Vincent <vincent.blondeau(a)worldline.com<mailto:vincent.blondeau@worldline.com>> wrote: Hi, It is very hard to work because Smalltalkhub is very instable today. I wanted to launch https://ci.inria.fr/moose/job/moose-6.0 but I get either an 400 or 500 errorâ¦ (It seems to work now but for how long?) Can somebody could look at this issue ? I restarted apacheâ¦which seems to be the source of the problem when loading static files makes problems. Marcus ________________________________ Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Oct. 7, 2015

Re: [Pharo-dev] Smalltalkhub instable

by Marcus Denker

> On 07 Oct 2015, at 15:47, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > > Hi, > > It is very hard to work because Smalltalkhub is very instable today. > I wanted to launch https://ci.inria.fr/moose/job/moose-6.0 <https://ci.inria.fr/moose/job/moose-6.0> but I get either an 400 or 500 errorâ¦ (It seems to work now but for how long?) > > Can somebody could look at this issue ? > I restarted apacheâ¦which seems to be the source of the problem when loading static files makes problems. Marcus

Oct. 7, 2015

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

by Marcus Denker

> 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. Marcus

Oct. 7, 2015

Problems with a large block

by Marco Naddeo

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

Oct. 7, 2015

Smalltalkhub instable

by Blondeau Vincent

Hi, It is very hard to work because Smalltalkhub is very instable today. I wanted to launch https://ci.inria.fr/moose/job/moose-6.0 but I get either an 400 or 500 error... (It seems to work now but for how long?) Can somebody could look at this issue ? Thanks in advance, Vincent BLONDEAU ________________________________ Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Oct. 7, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] 7c58b1: 50369

by Ferlicot D. Cyril

Le 07/10/2015 08:01, GitHub a Ã©crit : > Branch: refs/heads/5.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 7c58b1be0d0f72a2cdbb0f90ec6c374178b88efd > https://github.com/pharo-project/pharo-core/commit/7c58b1be0d0f72a2cdbb0f90… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2015-10-07 (Wed, 07 Oct 2015) > > Changed paths: > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50368.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50369.st > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50368.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50369.st > M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > Log Message: > ----------- > 50369 > 16732 DNU when cancel fetch on retrieve icon sets > https://pharo.fogbugz.com/f/cases/16732 > > 16577 Random should be in its own package > https://pharo.fogbugz.com/f/cases/16577 > > 16726 move Reflectivity-Styling to a separate package > https://pharo.fogbugz.com/f/cases/16726 > > http://files.pharo.org/image/50/50369.zip > > This seems light for 3 bugs correctionsâ¦ -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Oct. 7, 2015

Re: [Pharo-dev] [pharo-project/pharo-core] a40b39: 50371

by Esteban Lorenzano

this is *again* not true :( Esteban > On 07 Oct 2015, at 10:58, GitHub <noreply(a)github.com> wrote: > > Branch: refs/heads/5.0 > Home: https://github.com/pharo-project/pharo-core > Commit: a40b390a6696953585d4747751cfbf13737bba8f > https://github.com/pharo-project/pharo-core/commit/a40b390a6696953585d47477… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2015-10-07 (Wed, 07 Oct 2015) > > Changed paths: > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50370.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50371.st > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50370.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50371.st > M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > Log Message: > ----------- > 50371 > 16577 Random should be in its own package > https://pharo.fogbugz.com/f/cases/16577 > > http://files.pharo.org/image/50/50371.zip > >

Oct. 7, 2015

[pharo-project/pharo-core]

by GitHub

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

Oct. 7, 2015

[pharo-project/pharo-core] a40b39: 50371

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: a40b390a6696953585d4747751cfbf13737bba8f https://github.com/pharo-project/pharo-core/commit/a40b390a6696953585d47477… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-07 (Wed, 07 Oct 2015) Changed paths: R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50370.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50371.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50370.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50371.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50371 16577 Random should be in its own package https://pharo.fogbugz.com/f/cases/16577 http://files.pharo.org/image/50/50371.zip

Oct. 7, 2015

Re: [Pharo-dev] Using Pharo with Debian 8 64 bits

by Sven Van Caekenberghe

> On 07 Oct 2015, at 10:36, olivier auverlot <olivier.auverlot(a)gmail.com> wrote: > > Hi, > > I just tried to use Pharo 4 in graphical mode with Debian Jessy 64 bits. The last version of this Linux distribution needs some operations to running Pharo. I think that could be interesting to share my configuration work. > > - unzip the Pharo4 archive, > > - sudo dpkg --add-architecture i386 > - sudo apt-get update > - sudo apt-get install ia32-libs > > and now, the voodoo operations :-) > > - apt-get install libx11-6:386 > - apt-get install libgl1-mesa-glx:i386 > - apt-get install libfontconfig1:i386 > > Hope that's can help someone. > > Best regards > Olivier This is what I do: https://github.com/svenvc/pharo-server-tools/blob/master/ubuntu-32bit-suppo… but that is only for headless servers.

Oct. 7, 2015

Using Pharo with Debian 8 64 bits

by olivier auverlot

Hi, I just tried to use Pharo 4 in graphical mode with Debian Jessy 64 bits. The last version of this Linux distribution needs some operations to running Pharo. I think that could be interesting to share my configuration work. - unzip the Pharo4 archive, - sudo dpkg --add-architecture i386 - sudo apt-get update - sudo apt-get install ia32-libs and now, the voodoo operations :-) - apt-get install libx11-6:386 - apt-get install libgl1-mesa-glx:i386 - apt-get install libfontconfig1:i386 Hope that's can help someone. Best regards Olivier

Oct. 7, 2015

[pharo-project/pharo-core]

by GitHub

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

Oct. 7, 2015

[pharo-project/pharo-core] f77aec: 50370

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: f77aece8f2dc991436ea5a6c2c038be18da088ba https://github.com/pharo-project/pharo-core/commit/f77aece8f2dc991436ea5a6c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-07 (Wed, 07 Oct 2015) Changed paths: M Polymorph-Widgets.package/ThemeIcons.class/class/accessing/availablePacks.st M Polymorph-Widgets.package/ThemeIcons.class/class/settings/uiFetchPacks.st A Reflectivity-Examples.package/MetalinkIconStyler.class/README.md A Reflectivity-Examples.package/MetalinkIconStyler.class/definition.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/accessing/iconProvider.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/accessing/textModel.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/accessing/textModel_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/styling/addMetalinkMethodStyle_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/styling/addMetalinkStyle_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/styling/addMetalinkStyle_from_to_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/styling/addMetalinkStyle_from_to_color_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitArgumentNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitArrayNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitAssignmentNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitBlockNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitCascadeNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitGlobalNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitInstanceVariableNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitLiteralArrayNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitLiteralNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitMessageNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitMethodNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitParseErrorNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitPragmaNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitReturnNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitSelfNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitSequenceNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitSuperNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitTemporaryNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitThisContextNode_.st A Reflectivity-Examples.package/MetalinkIconStyler.class/instance/visiting/visitVariableNode_.st A Reflectivity-Examples.package/MetalinkTextSegmentMorph.class/README.md A Reflectivity-Examples.package/MetalinkTextSegmentMorph.class/definition.st R Reflectivity.package/MetalinkIconStyler.class/README.md R Reflectivity.package/MetalinkIconStyler.class/definition.st R Reflectivity.package/MetalinkIconStyler.class/instance/accessing/iconProvider.st R Reflectivity.package/MetalinkIconStyler.class/instance/accessing/textModel.st R Reflectivity.package/MetalinkIconStyler.class/instance/accessing/textModel_.st R Reflectivity.package/MetalinkIconStyler.class/instance/styling/addMetalinkMethodStyle_.st R Reflectivity.package/MetalinkIconStyler.class/instance/styling/addMetalinkStyle_.st R Reflectivity.package/MetalinkIconStyler.class/instance/styling/addMetalinkStyle_from_to_.st R Reflectivity.package/MetalinkIconStyler.class/instance/styling/addMetalinkStyle_from_to_color_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitArgumentNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitArrayNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitAssignmentNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitBlockNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitCascadeNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitGlobalNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitInstanceVariableNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitLiteralArrayNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitLiteralNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitMessageNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitMethodNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitParseErrorNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitPragmaNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitReturnNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitSelfNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitSequenceNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitSuperNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitTemporaryNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitThisContextNode_.st R Reflectivity.package/MetalinkIconStyler.class/instance/visiting/visitVariableNode_.st R Reflectivity.package/MetalinkTextSegmentMorph.class/README.md R Reflectivity.package/MetalinkTextSegmentMorph.class/definition.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50369.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50370.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50369.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50370.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50370 16726 move Reflectivity-Styling to a separate package https://pharo.fogbugz.com/f/cases/16726 16732 DNU when cancel fetch on retrieve icon sets https://pharo.fogbugz.com/f/cases/16732 http://files.pharo.org/image/50/50370.zip

Oct. 7, 2015

Re: [Pharo-dev] FogBugz-Filter

by Marcus Denker

Yes, I broke itâ¦ I have fixed it again to show all issues that need a review (monkey checked or not). Marcus > On 06 Oct 2015, at 22:19, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > https://pharo.fogbugz.com/default.asp?pg=pgManageFilters <https://pharo.fogbugz.com/default.asp?pg=pgManageFilters> (button next to cases > manage filters) > (or https://pharo.fogbugz.com/default.asp?pg=pgFilter&ixFilter=36 <https://pharo.fogbugz.com/default.asp?pg=pgFilter&ixFilter=36> ) > > Maybe caused by this http://forum.world.st/issue-tracker-6-issue-fixed-in-external-package-needs… <http://forum.world.st/issue-tracker-6-issue-fixed-in-external-package-needs…> ? > > > > On Tue, Oct 6, 2015 at 10:15 PM, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: > Someone changed the fogbugz filter "Fixed To Review" now it shows the same > results like "fixed upstream", how can it be changed it back? >

Oct. 7, 2015

Re: [Pharo-dev] About Magritte Seaside

by Stephan Eggermont

On 07/10/15 08:47, Christophe Demarey wrote: > If you have any question or remark, do not hesitate to ask or to give feedback. How do you express the migration of functionality from one package to another? How does that affect users of those packages? How do you intend to deal with variants (as in the 5D model)? Stephan

Oct. 7, 2015