- Pharo-dev - lists.pharo.org

Fwd: Re: Slowness question

by Hilaire Fernandes

-------- Message original -------- Sujet: Re: Slowness question Date : Thu, 5 Jun 2014 07:02:44 +0200 De : ClÃ©ment Bera <bera.clement(a)gmail.com> RÃ©pondre Ã : Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Pour : Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Groupes de discussion: gmane.comp.lang.smalltalk.pharo.user RÃ©fÃ©rences : <lmo29u$qu0$1(a)ger.gmane.org> Igor do you have a clue ? (I'm not sure Igor is on pharo-users) Clement 2014-06-04 23:15 GMT+02:00 Hilaire Fernandes <hilaire.fernandes(a)gmail.com <mailto:hilaire.fernandes@gmail.com>>: Hi, Programmed sketch in DrGeo can be animated, for example like the script bellow. The "canvas do:" message forks the block so user is not blocked. At #udpate message the items and views (morph) are recomputed and refreshed . Before porting DrGeo to Athens, the animation was pretty fast, now it is very slow. Any idea from where it could come from? Thanks ---8<------ |canvas s stats points| points :=Array new: 12. stats := Array new: 12 withAll: 0. canvas := DrGeoCanvas new. 2 to: 12 do: [:i | points at: i put: (canvas point: i(a)0.1) (points at: i) square; color: Color blue. s := canvas segment: i@0 to: (points at: i). s color: Color red]. canvas do: [ 1 to: 10000 do: [:i| s := 6 atRandom + 6 atRandom. stats at: s put: ((stats at: s)+1). (points at: s) name: (stats at: s) asString; moveTo: s @ ((stats at: s) / 100). canvas update]. ---8<------ -- Dr. Geo http://drgeo.eu

June 5, 2014

Re: [Pharo-dev] Brainstorming Pharo4

by Attila Magyar

In regard to improving tools. One of the most common criticism I hear about dynamically typed languages, is that you can't have precise code completion, and without this, it is impossible to know what methods can be used in given context. My usual response is, that you can, just ask the object what messages do you respond to. Then I explain what a live object is, and how coding inside the debugger work. The problem is, neither the Debugger nor the Workspace take advantages of this. If I start typing a message inside the Debugger, the code completion won't take the type of the receiver into consideration. -- View this message in context: http://forum.world.st/Brainstorming-Pharo4-tp4761647p4761805.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 5, 2014

Re: [Pharo-dev] Brainstorming Pharo4

by Hilaire Fernandes

Le 04/06/2014 20:53, stepharo a Ã©crit : >> As you mentioned a lot of new tools and protocols were introduced, >> people (me included) does not well about those ones. >> As an example I am slowly discovering announcement and now AFAIK the >> image use three different protocols for this: change/update, observer >> and Announcement! > Yes we know that the situation is not ideal. > We started to move more to announcement. The problem is that some of the > widgets > requires the change/update. For the observer I do not know what you mean. change/update when:send:to:/triggerEvent: Announcement This is just an example where developer get confused. This is why I beg for consolidations, incidentally more people may be capable to help (and learn) on these tasks -- Dr. Geo http://drgeo.eu

June 5, 2014

Re: [Pharo-dev] Brainstorming Pharo4

by Hilaire Fernandes

Le 04/06/2014 20:53, stepharo a Ã©crit : >> As an example I am slowly discovering announcement and now AFAIK the >> image use three different protocols for this: change/update, observer >> and Announcement! > Yes we know that the situation is not ideal. > We started to move more to announcement. The problem is that some of the > widgets > requires the change/update. For the observer I do not know what you mean. change/update when:send:to:/triggerEvent: Announcement This is just an example where developer get confused. This is why I beg for consolidations, incidentally more people may be capable to help on that tasks -- Dr. Geo http://drgeo.eu

June 5, 2014

Re: [Pharo-dev] issue validation needed

by Damien Cassou

On Wed, Jun 4, 2014 at 9:12 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > can someone check this metacello issue? > > https://pharo.fogbugz.com/f/cases/13305/ > > I really need it for continue with VM work. for the laziest among you: Problem resolving branches with Metacello The fix is in the Inbox -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 5, 2014

Re: [Pharo-dev] Pharo and Amber

by Damien Cassou

Hi Hannes, On Wed, Jun 4, 2014 at 6:10 PM, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: > tells me to do > TDDispatcher tideIndexPageUrl inspect > > which leads to a 'subscript out of bounds error'. > > Any suggestions? > How do I proceed to start the server and use Amber? I can reproduce your problem easily by *not* following the instructions on this page :-). I guess you just miss to evaluate: Metacello new configuration: 'Tide'; version: #development; repository: 'http://www.smalltalkhub.com/mc/Pharo/MetaRepoForPharo30/main'; load. Don't hesitate to ask again. I'm also on IRC if you want more rapid help. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

June 5, 2014

Re: [Pharo-dev] can not upload a slice to pharo40 inbox

by Nicolai Hess

But I think I am a registered user. At least I can login with the smalltalkhub weblogin. 2014-06-05 7:06 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Recently there was a bug in public repositories in smalltalkhub (non > registered users were not able to commit as if the repo was private). It > might be that. > > > 2014-06-04 22:57 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > when uploading a slice, I always get the following error: >> >> a ZnResponse(500 Internal Server Error text/plain;charset=utf-8 30B) >> >> any ideas? >> >> Nicolai >> > >

June 5, 2014

Re: [Pharo-dev] can not upload a slice to pharo40 inbox

by Nicolai Hess

2014-06-05 7:06 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Recently there was a bug in public repositories in smalltalkhub (non > registered users were not able to commit as if the repo was private). It > might be that. > > > 2014-06-04 22:57 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > when uploading a slice, I always get the following error: >> >> a ZnResponse(500 Internal Server Error text/plain;charset=utf-8 30B) >> >> any ideas? >> >> Nicolai >> > >

June 5, 2014

Re: [Pharo-dev] Brainstorming Pharo4

by Alexandre Bergel

+1 Alexandre On Jun 5, 2014, at 10:57 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Here is my short, ordered list: > > - VM should run as a normal 64-bit citizen with the current 32-bit address space > > (it is really annoying that we need 32-bit libraries, it hinders deployment on modern virtual hardware like Xen, Docker, .. - and it makes us look weird and old) > > - VM should break the 32-bit memory limitation and use a 64-bit address space > > (we are currently limited to 1GB of memory in use, http://forum.world.st/Pharo-dev-Exploring-Heap-Size-Limits-td4696226.html#a… - today's hardware easily offers many times more for little money, which we should be able to use for monolithic memory persistent data structures) > > - Modularity in the core development > > (we have to keep Pharo lean and mean, we cannot make another mess like the one we are still cleaning up) > > - Capitalize on our tool set by improving it > > (the magic of Pharo is, for a large part, situated in the IDE, but we have to invest in that area to remain relevant) > > Of course, handle format X, talk protocol Y, connect to database Z are all important, but can contributed externally. But to remain successful, we need a solid, modern base. > > Sven > > On 05 Jun 2014, at 10:14, phil(a)highoctane.be wrote: > >> On Thu, Jun 5, 2014 at 8:31 AM, FranÃ§ois Stephany <tulipe.moutarde(a)gmail.com> wrote: >> As Kilon say, this is a personal wishlist. Any direction you mentioned is worth and will have impact. >> >> However, here's my personal top 5: >> >> - **Git in the image**, that would be awesome to be able integrate the gitflow way of developing in team. Easy branching/merging is a must. >> - **Slots**. I still need to check the current implementation and see what's possible (Property slots?) but as I have understood you've planned even more for pharo4? >> - **Text Editor with sensible keybindings**. >> - **ARM support** >> - **Athens** >> >> Keybindings that do work on Linux >> VM on enterprise OS (CentOS/RHEL), including GLIBC < 2.15 >> Debugger that actually doesn't throws you in space after a couple of restart/through/over (this one really is taking power away from the whole experience) >> Faster UI in general >> Easier Git merges without metadata issues etc >> Ability to recover frozen images (as in "Oz") >> Ability to somehow get back control of the image through some mechanism at the VM level when frozen and no way to interrupt anything. I am ready to pay some performance in order to work that way. >> Removal of all passwords, including whatever could be in the .changes (which will disappear per se but you get my drift). >> +1 for Mpeg and Camera plugins; >> Traits should indeed be given a better treatment in Nautilus. >> >> Phil >> >> >> >> On Wed, Jun 4, 2014 at 9:06 PM, jannik laval <jannik.laval(a)gmail.com> wrote: >> Hi all, >> >> From my point of view, I like the progrss on the ARM VM. >> I hope to have an Android VM that works. >> Also I hope to see Pharo3.0 and Pharo4.0 working on iOS. >> >> Another question is about two interesting plugins: Mpeg3Plugin and CameraPlugin. >> Is it possible to integrate them in the VM build ? >> >> Thank you guys for all the work done. >> Jannik >> >> >> 2014-06-04 20:53 GMT+02:00 stepharo <stepharo(a)free.fr>: >> >> >> Hi Esteban, >> >> As you mentioned a lot of new tools and protocols were introduced, >> people (me included) does not well about those ones. >> As an example I am slowly discovering announcement and now AFAIK the >> image use three different protocols for this: change/update, observer >> and Announcement! >> Yes we know that the situation is not ideal. >> We started to move more to announcement. The problem is that some of the widgets >> requires the change/update. For the observer I do not know what you mean. >> >> >> Personally I beg for a great Pharo 4.x series of iterative >> cleaning+consolidations. >> >> Thanks >> >> Hilaire >> >> Le 04/06/2014 17:36, Esteban Lorenzano a Ã©crit : >> Hi, >> >> A couple of weeks ago we started to plan Pharo4. This work became stagnated for many reasons, but mainly because I needed to travel to Argentina. >> Now I'm slowly resuming the work and I wanted to share with you what we have been talking/dreaming. >> In esence, we have two important drivers for this release: >> >> 1) Improving tools >> Turns out that we have introduced a lot of kernel improvements (opal compiler, layouts, slots, etc.) and tools are still not aware of them. Even worst: we have traits since a lot of time and our tools are still now aware enough to provide good interoperability. >> But not just that: we have introduced things that are not well used yet: keybindings (who do not want a better keybindings structure... coherent and editable?), spec should allow us to continue enhancing existing tools and to replace old ones. >> >> 2) Modularisation >> One of the fundamental ideas behind Pharo is to provide a modular environment. But well... since Pharo start to the moment, we prepared things to allow it, but still few direct effort has been made. >> In our dreams, Pharo should be built starting for a small kernel image and adding different modules to get a complete version. In this idea Pharo=Kernel+GUI(Morphic)+Tools. >> This has huge advantages (I do not think is necesary to explain them, isn't ;)?) >> >> We brainstomed around this and we get this list of issues (not all of them directly related to the objectives, but well... good stuff also :) ) >> >> Web site: >> - add catalog >> - add videos >> - enhance it in general >> >> Infrastructure: >> - support more vm platforms >> >> VM: >> - spur >> - 64bits >> - make vm embedable and UI independent (with SDL2 and OSWindow) >> >> Image: >> - Modularisation >> - Removing old compiler >> - Repackage Morphic (to allow better modularisation) >> - Athens (replace old bitblt) >> >> Tools >> - Replace changes with Ombu/Epicea >> - Replace sources with a better abstraction >> - Git support inside image (with libgit2 + tools) >> - Pass on Spec >> - Include Glamour? >> - Make Ring unloadable >> - Fonts with FreeType >> >> And lots of bugfixes :) >> >> We would like to exchange ideas with you. >> So, what do you think? >> >> Esteban >> >> >> >> >> >> >> >> >> -- >> ~~Jannik Laval~~ >> Ãcole des Mines de Douai >> Enseignant-chercheur >> http://www.jannik-laval.eu >> http://www.phratch.com >> http://car.mines-douai.fr/ >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 5, 2014

Re: [Pharo-dev] Brainstorming Pharo4

by kilon alios

yeap I agree, 64bit is number one ... time for pharo to join with the others. On Thu, Jun 5, 2014 at 12:46 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > I can subscribe to most what others have said. Your list is pretty good > and I like even the order of things. Only a few additions. > > âImproving toolsâ: One aspect is making the tools aware of new > achievements in the core. Another aspect is to finish things that did > change in the past like e.g. keybindings. Nautilus uses new keyboard > shortcut while other tools use old ones. That is killing the development > experience. > > âModularizationâ: I think this should be _the_ goal for pharo4: Changing > the whole build process to a bootstrap+module approach. This is a huge step > IMHO. To make it more modular also means things can get smaller and > smaller. This also raises the necessity of having remote debugging tools > because UI is suspect to not being there. This step will also improve the > way we can manage deployed images which is especially important for a > company like mine. And I hope having decent remote enabled model will also > open new possibilities for image interoperation. > > 64bit vm: Like sven said it is necessary for us to have at least a 64bit > vm with a 32bit address space. Without that we are somewhat way behind what > is normal for others. 64bit address space should be a goal for pharo5. > > Slots: I would like it to see Slots being usable. It enables people to > play with new things without having to tweak the vm. And I like all > magritte like stuff being handled by slots which will improve the situation > a lot. And thatâs one thing that sets us way ahead of what is normal for > others. > > Remove old compiler for obvious reasons. > > So that would be one to two tasks for areas of improve existing > (maintenance), change for the better, distribution and cleanup. That would > be all for pharo4 for me. > > Norbert > > > Am 04.06.2014 um 17:36 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: > > > Hi, > > > > A couple of weeks ago we started to plan Pharo4. This work became > stagnated for many reasons, but mainly because I needed to travel to > Argentina. > > Now I'm slowly resuming the work and I wanted to share with you what we > have been talking/dreaming. > > In esence, we have two important drivers for this release: > > > > 1) Improving tools > > Turns out that we have introduced a lot of kernel improvements (opal > compiler, layouts, slots, etc.) and tools are still not aware of them. Even > worst: we have traits since a lot of time and our tools are still now aware > enough to provide good interoperability. > > But not just that: we have introduced things that are not well used yet: > keybindings (who do not want a better keybindings structure... coherent and > editable?), spec should allow us to continue enhancing existing tools and > to replace old ones. > > > > 2) Modularisation > > One of the fundamental ideas behind Pharo is to provide a modular > environment. But well... since Pharo start to the moment, we prepared > things to allow it, but still few direct effort has been made. > > In our dreams, Pharo should be built starting for a small kernel image > and adding different modules to get a complete version. In this idea > Pharo=Kernel+GUI(Morphic)+Tools. > > This has huge advantages (I do not think is necesary to explain them, > isn't ;)?) > > > > We brainstomed around this and we get this list of issues (not all of > them directly related to the objectives, but well... good stuff also :) ) > > > > Web site: > > - add catalog > > - add videos > > - enhance it in general > > > > Infrastructure: > > - support more vm platforms > > > > VM: > > - spur > > - 64bits > > - make vm embedable and UI independent (with SDL2 and OSWindow) > > > > Image: > > - Modularisation > > - Removing old compiler > > - Repackage Morphic (to allow better modularisation) > > - Athens (replace old bitblt) > > > > Tools > > - Replace changes with Ombu/Epicea > > - Replace sources with a better abstraction > > - Git support inside image (with libgit2 + tools) > > - Pass on Spec > > - Include Glamour? > > - Make Ring unloadable > > - Fonts with FreeType > > > > And lots of bugfixes :) > > > > We would like to exchange ideas with you. > > So, what do you think? > > > > Esteban > > > > > > >

June 5, 2014