- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 8418a3: 30793

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 8418a3fb5bba1056099d38b5e6759db327437dea https://github.com/pharo-project/pharo-core/commit/8418a3fb5bba1056099d38b5… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-03-11 (Tue, 11 Mar 2014) Changed paths: M Kernel.package/ContextPart.class/instance/controlling/runUntilErrorOrReturnFrom_.st A OpalCompiler-Core.package/OCASTTranslatorForEffect.class/instance/visitor-double dispatching/visitLiteralArrayNode_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script446.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30793.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-Debugger.package/SpecDebugger.class/instance/updating/updateContextInspectorFromContext_.st M Spec-Debugger.package/SpecDebugger.class/instance/updating/updateInspectorsFromContext_.st A Spec-Debugger.package/SpecDebugger.class/instance/updating/updateReceiverInspectorFromContext_.st Log Message: ----------- 30793 5041 ContextPart>>#runUntilErrorOrReturnFrom: https://pharo.fogbugz.com/f/cases/5041 12722 #ifNil:#ifNotNil: must return a value? https://pharo.fogbugz.com/f/cases/12722 12699 Debugger clears selection on update https://pharo.fogbugz.com/f/cases/12699 http://files.pharo.org/image/30/30793.zip

March 11, 2014

Re: [Pharo-dev] Touch Events VM changes

by J.F. Rick

Hi Sergi, Based on my experience developing touch interfaces since 2007, I believe in touch. I believe it will be the future of interfaces and I believe it can be better than mouse-keyboard interfaces. That said, it is not there yet. Now is the time to innovate and get it there so that touch interfaces won't be poor replicas of their desktop forebears. Currently, text entry is a real problem for touch exclusive devices, but there is progress being made on that front. We don't have the answer yet but I think it will be a significantly different landscape in five years. In regards to touch vs physical pointers, this is not as large of a problem as people make it out to be. It is just that our widgets tend to be created for mouse-based interfaces and therefore don't transition well to touch. Interfaces designed with touch in mind can be just as smooth (if not smoother) as mouse-based interfaces. You just have to take advantage of what touch does well (faster, more precise routes; multi-touch gestures; bimanual interaction) and stay clear of things it does poorly (precise touch down, covering the target with the finger). Cheers, Jeff On Tue, Mar 11, 2014 at 12:34 PM, Sergi Reyner <sergi.reyner(a)gmail.com>wrote: > 2014-03-11 10:37 GMT+00:00 J.F. Rick <self(a)je77.com>: > > As we move from mouse-keyboard devices to touch-based ones > > > I certainly hope that "we" refers to a small group of people, unless we > get onscreen keyboards as good as physical ones, feedback included. The > same goes for touch versus physical pointer :) > > Cheers, > Sergi > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

March 11, 2014

Access to MetaRepoForPharo30

by Gabriel Cotelli

Hi guys, can you add me as a contributor to the MetaRepoForPharo30 project? My sthub user is gcotelli Gabriel

March 11, 2014

Re: [Pharo-dev] Touch Events VM changes

by J.F. Rick

Definitely agreed on the strategy of processing the raw events on the image side as that will be much more flexible. But, we still need the VM to send the raw events. I'll check on the vm-dev list. I think I'm already subscribed to it. Cheers, Jeff On Tue, Mar 11, 2014 at 12:03 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > Hi, > > I agree that we need a unified event model. Now... our vision is to solve > that in image side, not in vm (and vm should send the raw events "as is"). > The reason of why we want it in image is easy: image means pharo, and it > means more hands (or eyes) over it. Then is easier to maintain :) > Anyway, we are slowly working on it (See Igor & Ronnie work around > OSWindow). But is probably too slow :) > > Esteban > > On 11 Mar 2014, at 11:37, J.F. Rick <self(a)je77.com> wrote: > > As we move from mouse-keyboard devices to touch-based ones, it would be > nice if we could unify touch development across the different Pharo > platforms (iOS, Android, Windows 8, Linux, etc.), so that we can start to > build touch-aware widgets and frameworks. Currently, there's a lot of > interest but no unified movement. For instance, I've got a very nice > multi-touch 27" computer that I run in Linux. I develop the applications in > Pharo but I currently use a hack to get the touch events: I use OSProcess > to start the mtdev2tuio application that takes touch input and sends it via > TUIO. I then use a UDP socket to read the events on Pharo. If I am to share > my work, I need to get beyond the hack. I (or rather Igor as I watched) > investigated the possibility of using NativeBoost calls to do the same, but > it would not work since mtdev2tuio has to run as superuser, meaning Pharo > would have to run as superuser. We came to the conclusion that this must be > a VM-level change. > > I'm not a VM hacker but would like to reach the people who maintain the > linux and windows VM to see if this might not be a reasonable addition to > the standard VM. There does seem to be standard support for touch events in > XFree86, so it shouldn't be too large a change on Linux. I assume that > Windows 8 similarly makes touch events available. Is this the right place > to ask or is there another mailing list (e.g., the cog-vm)? > > Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > > > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

March 11, 2014

Re: [Pharo-dev] Touch Events VM changes

by ClÃ©ment Bera

Hello, the right place is vm-dev. I put it in CC. Regards, 2014-03-11 11:37 GMT+01:00 J.F. Rick <self(a)je77.com>: > As we move from mouse-keyboard devices to touch-based ones, it would be > nice if we could unify touch development across the different Pharo > platforms (iOS, Android, Windows 8, Linux, etc.), so that we can start to > build touch-aware widgets and frameworks. Currently, there's a lot of > interest but no unified movement. For instance, I've got a very nice > multi-touch 27" computer that I run in Linux. I develop the applications in > Pharo but I currently use a hack to get the touch events: I use OSProcess > to start the mtdev2tuio application that takes touch input and sends it via > TUIO. I then use a UDP socket to read the events on Pharo. If I am to share > my work, I need to get beyond the hack. I (or rather Igor as I watched) > investigated the possibility of using NativeBoost calls to do the same, but > it would not work since mtdev2tuio has to run as superuser, meaning Pharo > would have to run as superuser. We came to the conclusion that this must be > a VM-level change. > > I'm not a VM hacker but would like to reach the people who maintain the > linux and windows VM to see if this might not be a reasonable addition to > the standard VM. There does seem to be standard support for touch events in > XFree86, so it shouldn't be too large a change on Linux. I assume that > Windows 8 similarly makes touch events available. Is this the right place > to ask or is there another mailing list (e.g., the cog-vm)? > > Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick >

March 11, 2014

Re: [Pharo-dev] Touch Events VM changes

by Sergi Reyner

2014-03-11 10:37 GMT+00:00 J.F. Rick <self(a)je77.com>: > As we move from mouse-keyboard devices to touch-based ones I certainly hope that "we" refers to a small group of people, unless we get onscreen keyboards as good as physical ones, feedback included. The same goes for touch versus physical pointer :) Cheers, Sergi

March 11, 2014

Re: [Pharo-dev] Touch Events VM changes

by btc＠openinworld.com

J.F. Rick wrote: > As we move from mouse-keyboard devices to touch-based ones, it would > be nice if we could unify touch development across the different Pharo > platforms (iOS, Android, Windows 8, Linux, etc.), so that we can start > to build touch-aware widgets and frameworks. Currently, there's a lot > of interest but no unified movement. For instance, I've got a very > nice multi-touch 27" computer that I run in Linux. I develop the > applications in Pharo but I currently use a hack to get the touch > events: I use OSProcess to start the mtdev2tuio application that takes > touch input and sends it via TUIO. I then use a UDP socket to read the > events on Pharo. If I am to share my work, I need to get beyond the > hack. I (or rather Igor as I watched) investigated the possibility of > using NativeBoost calls to do the same, but it would not work since > mtdev2tuio has to run as superuser, meaning Pharo would have to run as > superuser. We came to the conclusion that this must be a VM-level change. > > I'm not a VM hacker but would like to reach the people who maintain > the linux and windows VM to see if this might not be a reasonable > addition to the standard VM. There does seem to be standard support > for touch events in XFree86, so it shouldn't be too large a change on > Linux. I assume that Windows 8 similarly makes touch events available. > Is this the right place to ask or is there another mailing list (e.g., > the cog-vm)? The place to ask is [vm-dev] http://lists.squeakfoundation.org/mailman/listinfo/vm-dev > > Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick

March 11, 2014

Re: [Pharo-dev] Touch Events VM changes

by Esteban Lorenzano

Hi, I agree that we need a unified event model. Nowâ¦ our vision is to solve that in image side, not in vm (and vm should send the raw events âas isâ). The reason of why we want it in image is easy: image means pharo, and it means more hands (or eyes) over it. Then is easier to maintain :) Anyway, we are slowly working on it (See Igor & Ronnie work around OSWindow). But is probably too slow :) Esteban On 11 Mar 2014, at 11:37, J.F. Rick <self(a)je77.com> wrote: > As we move from mouse-keyboard devices to touch-based ones, it would be nice if we could unify touch development across the different Pharo platforms (iOS, Android, Windows 8, Linux, etc.), so that we can start to build touch-aware widgets and frameworks. Currently, there's a lot of interest but no unified movement. For instance, I've got a very nice multi-touch 27" computer that I run in Linux. I develop the applications in Pharo but I currently use a hack to get the touch events: I use OSProcess to start the mtdev2tuio application that takes touch input and sends it via TUIO. I then use a UDP socket to read the events on Pharo. If I am to share my work, I need to get beyond the hack. I (or rather Igor as I watched) investigated the possibility of using NativeBoost calls to do the same, but it would not work since mtdev2tuio has to run as superuser, meaning Pharo would have to run as superuser. We came to the conclusion that this must be a VM-level change. > > I'm not a VM hacker but would like to reach the people who maintain the linux and windows VM to see if this might not be a reasonable addition to the standard VM. There does seem to be standard support for touch events in XFree86, so it shouldn't be too large a change on Linux. I assume that Windows 8 similarly makes touch events available. Is this the right place to ask or is there another mailing list (e.g., the cog-vm)? > > Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick

March 11, 2014

Touch Events VM changes

by J.F. Rick

As we move from mouse-keyboard devices to touch-based ones, it would be nice if we could unify touch development across the different Pharo platforms (iOS, Android, Windows 8, Linux, etc.), so that we can start to build touch-aware widgets and frameworks. Currently, there's a lot of interest but no unified movement. For instance, I've got a very nice multi-touch 27" computer that I run in Linux. I develop the applications in Pharo but I currently use a hack to get the touch events: I use OSProcess to start the mtdev2tuio application that takes touch input and sends it via TUIO. I then use a UDP socket to read the events on Pharo. If I am to share my work, I need to get beyond the hack. I (or rather Igor as I watched) investigated the possibility of using NativeBoost calls to do the same, but it would not work since mtdev2tuio has to run as superuser, meaning Pharo would have to run as superuser. We came to the conclusion that this must be a VM-level change. I'm not a VM hacker but would like to reach the people who maintain the linux and windows VM to see if this might not be a reasonable addition to the standard VM. There does seem to be standard support for touch events in XFree86, so it shouldn't be too large a change on Linux. I assume that Windows 8 similarly makes touch events available. Is this the right place to ask or is there another mailing list (e.g., the cog-vm)? Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

March 11, 2014

Re: [Pharo-dev] Sort by property

by ClÃ©ment Bera

Hello, @Uko Well I implemented Symbol>>value:value: in a similar fashion than Symbol>>value: for 'aCollection collect: #aSymbol'. But that's not a perfect solution for sure. @Camille I used PluggableSet and PluggableDictionary in my project and they were so slow that in the end I implemented my own collection. It will be a real alternative when we will have clean blocks. (For that we need to merge with Cog's trunk which includes merging Spur)... 2014-03-11 10:45 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > > On 11 Mar 2014, at 10:19, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello, > > [ Note: So in the default Pharo the method is named #sort: not #sortByProp: > or #sortBy: but it's a detail ] > > > Yes, my mistake, I was misguided by #isSortedBy: > > Now #sortByProp: is my own example method that accepts a block and > executes it for each sortable item and then the result is compared. > > I don't like the idea to implement #value:value: for a symbol because it > caries a bit of a logic inside it. > > Uko > > > I like this idea because I also have always the problem. So I would like > to be able to do: > > projects sort: #creationDate > > The implementation would be, in a similar fashion to how Symbol>>value: is > implemented for aCollection collect: #isPlague : > > Symbol>>value: val1 value: val2 > ^ (val1 perform: self) <= (val2 perform: self) > > Then : > > (#( 10 42 31 23 90 87 65) collect: #asValueHolder) sort: #value > > Answers: > > an Array(a NewValueHolder[ 10 ] a NewValueHolder[ 23 ] a NewValueHolder[ > 31 ] a NewValueHolder[ 42 ] a NewValueHolder[ 65 ] a NewValueHolder[ 87 ] a > NewValueHolder[ 90 ]) > > which is correct :-). > > However I do not like: > > projects sort: [ :proj | proj author birthDate ] > > If you allow that where is the limit to the thing you want to allow ? In > addition, I do not see any nice implementation and you could just > implement in project > > Project>>authorBirthDate > ^ self author birthDate > > Best, > > Clement > > > > 2014-03-11 9:19 GMT+01:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > >> Hi guys. >> >> This is a thing that I encounter quite often. >> >> Eg I have a collection of projects and I want to sort them by creation >> date. It would be nice to be able to do something like: >> >> projects sortByProp: #creationDate >> >> or by birth date of the author >> >> projects sortByProp: [ :proj | proj author birthDate ] >> >> Maybe I'm wrong, but as I've told already I encounter it quite often and >> writing something like >> >> projects sortBy: [ :prev :next | prev creationDate <= next creationDate ] >> >> is boring for me. >> >> Cheers. >> Uko >> > > >

March 11, 2014