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

Re: [Pharo-dev] Smalltalkhub: Cannot add user to team: "Invalid username or password"

by Mariano Martinez Peck

WTF... I had my user remember in Chrome.. clicking Logout would do NOTHING. There was no way of logging out unless I clear everything from chrome... Then, opened firefox, login fresh, and yeah, I was able to edit team..wtf. #WindowsLikeTipsDoWork :) Thanks! On Thu, Nov 19, 2015 at 12:15 PM, Esteban A. Maringolo <emaringolo(a)gmail.com > wrote: > Did you try logging out and in of SmalltalkHub? > > #WindowsLikeTips :-o > Esteban A. Maringolo > > > 2015-11-19 12:07 GMT-03:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > no one? :( > > > > On Wed, Nov 18, 2015 at 9:34 AM, Mariano Martinez Peck > > <marianopeck(a)gmail.com> wrote: > >> > >> Hi guys, > >> > >> I am trying to add a registered user into my team via Edit Team -> add > >> button and I get a "Invalid username or password" error. Note that I > >> selected the user from the autocomplete... so the username should be > >> correct. > >> > >> Any ideas? > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Nov. 19, 2015

Re: [Pharo-dev] News about FastTable

by Thierry Goubier

2015-11-19 15:46 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > On 19/11/15 13:17, Thierry Goubier wrote: > >> Maybe. I haven't checked if the rule above holds for multi-selection. >> > > Looking in some more detail at it, the behaviour of Thunderbird seems > incorrect. Collapse and expand should restore the selection. I might want > to add en element to the selection that is much easier reached by > collapsing a subtree. Thunderbird loses the selection, and doesn't indicate > how much of the subtree is selected. Hum, it may be an interesting feature to have. But... I have a very clear idea of how complex that feature you are asking for is to implement properly in the general case and I won't consider implementing it if there is no strong justification for it. I'd prefer FTTree to get the basics right and, maybe, let the application track down that level of complexity if needed(*). I do find the FT core code to already carry far too much features (search, filtering) for my confort. (*) In no less part because it may make the component very slow for very large trees, so I'd consider this is an application level decision to implement such a feature, because the application knows if it is dealing with large or small trees. > > Maybe it could be left to the application using the widget, >> but, even at that level, writing it properly is hard (and it would be >> good that the toolkit provides for proper behavior to make the life of >> the application designer easier). >> > > The best way to ensure consistency is to make it easy to do the right > thing, yes. But be reasonable in what you ask. As far as I can see, FT doesn't have a proper drag and drop behavior yet. Thierry > > > Stephan > > >

Nov. 19, 2015

Re: [Pharo-dev] Preparing for the (already here) future world of multi-core PCs

by EuanM

Maybe a 'pack' of Seasides is the wrong collective. A 'shoreline' of Seasides? A 'coast'? On 19 November 2015 at 15:22, EuanM <euanmee(a)gmail.com> wrote: > There are also uses that don't involve the GPU - any headless server > use, e.g. running a pack of headless Seasides. > > Ways to deal with the machine becoming IO bound is definitely one of > the key issues. > > I'm not saying anything is preventing it - I'm saying that one of the > key enablers are tools to support it. > > On 19 November 2015 at 12:58, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >> Now days the real CPU is the GPU. Most of the acceleration and parrarel >> computing happens in there. >> >> Eventhough my fellow pharo collogues are mostly purists that prefer >> everything implemented in Pharo I am a parasitist preffering to leach off >> any technology I can find, my favourite choice being python. Its possible to >> use my socket bridge to bridge pharo with python in a few dozen lines of >> code to access to 2 python libraries, multiprocessing and foremost PyCuda so >> you can both take advantage the multiple cores of a CPU and an GPU though >> GPU should be your prime focus if you want considerably speed ups to your >> code. >> >> So none stops a pharoers making code that runs on multiple CPU and GPUs , >> all it takes is a bit of imagination and an open mind. Sometimes the >> quickest way to reach a goal is not a straight line . >> >> The truth however is even I that works with 3d graphics I find myself barely >> needing 1 CPU core, so you need to first make sure that you need such a >> feature before implementing it. >> >> On Thu, Nov 19, 2015 at 4:19 AM EuanM <euanmee(a)gmail.com> wrote: >>> >>> I agree that parallelism and concurrency are different things. >>> >>> For easy parallelism : >>> - a multi-VM version of something like PharoLauncher. >>> - tools for tailor each VM + Image >>> - tools to manage and track each running VM + Image. >>> - tolls to try to mak sure that different running VMs and images have >>> their own core, and that VMs can be closed down so that VMs never are >>> sharing (unless you want them to) >>> >>> All we need to do is make sure that the VM and image don't have >>> baked-in assumptions about being the only VM on the physical machine >>> baked in to each VM and the Smalltalk above it.) >>> >>> The task for the end-user app developers then becomes seeing what >>> bundles of functionality are sufficiently decoupled from the others >>> that they can be set adrift in their own VM. >>> >>> (I'm even starting to think of reinventing the multi-user server. A >>> single 16 core PC, with 16 4-core Raspberry Pis connected, and each >>> RPi's user taking control of a single app on a single VM single core >>> on the PC). >>> >>> (Then you could have a quite a decent network for $140 per workstation >>> (PiCEED + keyboard + mouse) , and one fast laptop as the central >>> server Cheap, and easy to transport to remote locations. (But I >>> digress) >>> >>> >>> Concurrency is a deeper and harder problem for a Smalltalk, I agree. >>> >>> >>> >>> On 18 November 2015 at 23:36, Michael J. Forster <mike(a)sharedlogic.ca> >>> wrote: >>> > This is no small issue, nor a single one. >>> > >>> > Be careful to distinguish concurrency from parallelism. See Rob Pike's >>> > talk/slides on this. >>> > >>> > Note that many systems can benefit from a concurrent design--even on a >>> > single core, where no parallel execution is possible--because the >>> > problem is >>> > inherently concurrent; note how effectively shared-nothing approaches >>> > with >>> > Erlang, Go, or Scala/Akka have been used in such domains. >>> > >>> > In other domains, parallelism--especially nested data parallelism--is >>> > more >>> > important than concurrency (see >>> > >>> > http://yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html) >>> > The Haskell and other communities have been exploring this with shared >>> > memory approaches like STM. >>> > >>> > So, to better use the slowing but increasing number of cores in today's >>> > hardware, we need to understand the many very different use cases and >>> > approaches. The lowest-hanging fruit in the Pharo/Squeak world might be >>> > to >>> > rework the vm and process scheduler to support massive numbers of >>> > lighter >>> > weight processes similar to Erlang. Check out Andrew Blacks "Erlang in >>> > Pharo", http://www.squeaksource.com/Erlang.html. >>> > >>> > Best, >>> > >>> > Mike >>> > >>> > >>> > >>> > >>> > -- >>> > View this message in context: >>> > http://forum.world.st/Preparing-for-the-already-here-future-world-of-multi-… >>> > Sent from the Pharo Smalltalk Developers mailing list archive at >>> > Nabble.com. >>> > >>> >>

Nov. 19, 2015

Re: [Pharo-dev] Preparing for the (already here) future world of multi-core PCs

by EuanM

There are also uses that don't involve the GPU - any headless server use, e.g. running a pack of headless Seasides. Ways to deal with the machine becoming IO bound is definitely one of the key issues. I'm not saying anything is preventing it - I'm saying that one of the key enablers are tools to support it. On 19 November 2015 at 12:58, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Now days the real CPU is the GPU. Most of the acceleration and parrarel > computing happens in there. > > Eventhough my fellow pharo collogues are mostly purists that prefer > everything implemented in Pharo I am a parasitist preffering to leach off > any technology I can find, my favourite choice being python. Its possible to > use my socket bridge to bridge pharo with python in a few dozen lines of > code to access to 2 python libraries, multiprocessing and foremost PyCuda so > you can both take advantage the multiple cores of a CPU and an GPU though > GPU should be your prime focus if you want considerably speed ups to your > code. > > So none stops a pharoers making code that runs on multiple CPU and GPUs , > all it takes is a bit of imagination and an open mind. Sometimes the > quickest way to reach a goal is not a straight line . > > The truth however is even I that works with 3d graphics I find myself barely > needing 1 CPU core, so you need to first make sure that you need such a > feature before implementing it. > > On Thu, Nov 19, 2015 at 4:19 AM EuanM <euanmee(a)gmail.com> wrote: >> >> I agree that parallelism and concurrency are different things. >> >> For easy parallelism : >> - a multi-VM version of something like PharoLauncher. >> - tools for tailor each VM + Image >> - tools to manage and track each running VM + Image. >> - tolls to try to mak sure that different running VMs and images have >> their own core, and that VMs can be closed down so that VMs never are >> sharing (unless you want them to) >> >> All we need to do is make sure that the VM and image don't have >> baked-in assumptions about being the only VM on the physical machine >> baked in to each VM and the Smalltalk above it.) >> >> The task for the end-user app developers then becomes seeing what >> bundles of functionality are sufficiently decoupled from the others >> that they can be set adrift in their own VM. >> >> (I'm even starting to think of reinventing the multi-user server. A >> single 16 core PC, with 16 4-core Raspberry Pis connected, and each >> RPi's user taking control of a single app on a single VM single core >> on the PC). >> >> (Then you could have a quite a decent network for $140 per workstation >> (PiCEED + keyboard + mouse) , and one fast laptop as the central >> server Cheap, and easy to transport to remote locations. (But I >> digress) >> >> >> Concurrency is a deeper and harder problem for a Smalltalk, I agree. >> >> >> >> On 18 November 2015 at 23:36, Michael J. Forster <mike(a)sharedlogic.ca> >> wrote: >> > This is no small issue, nor a single one. >> > >> > Be careful to distinguish concurrency from parallelism. See Rob Pike's >> > talk/slides on this. >> > >> > Note that many systems can benefit from a concurrent design--even on a >> > single core, where no parallel execution is possible--because the >> > problem is >> > inherently concurrent; note how effectively shared-nothing approaches >> > with >> > Erlang, Go, or Scala/Akka have been used in such domains. >> > >> > In other domains, parallelism--especially nested data parallelism--is >> > more >> > important than concurrency (see >> > >> > http://yosefk.com/blog/parallelism-and-concurrency-need-different-tools.html) >> > The Haskell and other communities have been exploring this with shared >> > memory approaches like STM. >> > >> > So, to better use the slowing but increasing number of cores in today's >> > hardware, we need to understand the many very different use cases and >> > approaches. The lowest-hanging fruit in the Pharo/Squeak world might be >> > to >> > rework the vm and process scheduler to support massive numbers of >> > lighter >> > weight processes similar to Erlang. Check out Andrew Blacks "Erlang in >> > Pharo", http://www.squeaksource.com/Erlang.html. >> > >> > Best, >> > >> > Mike >> > >> > >> > >> > >> > -- >> > View this message in context: >> > http://forum.world.st/Preparing-for-the-already-here-future-world-of-multi-… >> > Sent from the Pharo Smalltalk Developers mailing list archive at >> > Nabble.com. >> > >> >

Nov. 19, 2015

Re: [Pharo-dev] ConfigurationOfIDE working again

by Ben Coman

Cool. Thanks for the update. cheers -ben On Thu, Nov 19, 2015 at 6:16 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > the job for ConfigurationOfIDE that loads GUI and tools (not all for now) to > minimal Pharo is now producing usable image again.: > > https://ci.inria.fr/pharo/view/5.0-SysConf/job/Pharo-5.0-ConfigurationOfIDE/ > > We definitely need to find a way how to keep it green and improve and clean > it instead of spending one forenoon once in a while by fixing it ;-) > > Cheers, > -- Pavel

Nov. 19, 2015

Re: [Pharo-dev] Smalltalkhub: Cannot add user to team: "Invalid username or password"

by Esteban A. Maringolo

Did you try logging out and in of SmalltalkHub? #WindowsLikeTips :-o Esteban A. Maringolo 2015-11-19 12:07 GMT-03:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > no one? :( > > On Wed, Nov 18, 2015 at 9:34 AM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> Hi guys, >> >> I am trying to add a registered user into my team via Edit Team -> add >> button and I get a "Invalid username or password" error. Note that I >> selected the user from the autocomplete... so the username should be >> correct. >> >> Any ideas? >> >> -- >> Mariano >> http://marianopeck.wordpress.com > > > > > -- > Mariano > http://marianopeck.wordpress.com

Nov. 19, 2015

Re: [Pharo-dev] Smalltalkhub: Cannot add user to team: "Invalid username or password"

by Mariano Martinez Peck

no one? :( On Wed, Nov 18, 2015 at 9:34 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys, > > I am trying to add a registered user into my team via Edit Team -> add > button and I get a "Invalid username or password" error. Note that I > selected the user from the autocomplete... so the username should be > correct. > > Any ideas? > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Nov. 19, 2015

Re: [Pharo-dev] News about FastTable

by Stephan Eggermont

On 19/11/15 13:17, Thierry Goubier wrote: > Maybe. I haven't checked if the rule above holds for multi-selection. Looking in some more detail at it, the behaviour of Thunderbird seems incorrect. Collapse and expand should restore the selection. I might want to add en element to the selection that is much easier reached by collapsing a subtree. Thunderbird loses the selection, and doesn't indicate how much of the subtree is selected. > Maybe it could be left to the application using the widget, > but, even at that level, writing it properly is hard (and it would be > good that the toolkit provides for proper behavior to make the life of > the application designer easier). The best way to ensure consistency is to make it easy to do the right thing, yes. Stephan

Nov. 19, 2015

Re: [Pharo-dev] EyeInspector with subclasses of ProtoObject

by Tudor Girba

Hi, Please tell me more specifically what needs to be done. Could you give me a concrete example of an object that cannot be inspected? Cheers, Tudor > On Nov 18, 2015, at 6:08 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > 2015-11-18 13:29 GMT-03:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >> >> 2015-11-18 8:43 GMT-03:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>> Iâd like to discuss also the possibility to add those low level operations >>> on mirrors objects, that could be packaged separately from the kernel of the >>> language. Adding them on a first step is easy, then making all tools use >>> them is the hard/timeconsuming part, yes. >> >> >> All the needed operations already exist. You can put them on your mirror >> objects without any problem. > > > Who takes the decision to put it either in EyeInspector or GtInspector? > > Regards! > -- www.tudorgirba.com "Be rather willing to give than demanding to get."

Nov. 19, 2015

Re: [Pharo-dev] EyeInspector with subclasses of ProtoObject

by Esteban A. Maringolo

2015-11-19 7:22 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > On 19-11-15 10:33, Guillermo Polito wrote: >> >> I know we can :) and I did some prototypes already as part of my thesis. >> >> The question is if that is a design we *want* or not. > > > 1 Is it an improvement on the current situation? Yes. > 2 Is it blocking an improvement direction we want to take? Debugging/Inspecting Proxies and other ProtoObjects is barely supported by the current tools. > 3 Can it be tested quickly? No idea. Esteban A. Maringolo

Nov. 19, 2015