March 2014 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] About inspectors

by Tudor Girba

Thanks. I was looking for something like that! I will check it and get back to you. Doru On Tue, Mar 11, 2014 at 10:42 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Doru, for the DBXTalk inspector, maybe it is useful for you this package: > > http://www.smalltalkhub.com/#!/~DBXTalk/DBXDatabaseModel/ > > That allows to retrieve database schema metadata in a polymorphic way :) > > > On Tue, Mar 11, 2014 at 7:43 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Thank you. >> >> In this case yes, it blurs the line between an SQL Editor and the >> inspector. And between a table and an Excel code editor. But, here is >> another blurred line between the file browser and the inspector: >> >> http://www.humane-assessment.com/blog/browsing-files-with-gtinspector-video/ >> >> The GTInspector blurs all sorts of lines and it even empowers you to blur >> your own lines :). >> >> Just a note: the GToolkit is also the work of Andrei. >> >> Doru >> >> >> On Mon, Mar 10, 2014 at 8:01 PM, Esteban A. Maringolo < >> emaringolo(a)gmail.com> wrote: >> >>> Excellent Tudor! >>> >>> Very impressive. It blurs the line between a the Smalltalk tools and >>> an SQL Editor. >>> Esteban A. Maringolo >>> >>> >>> 2014-03-10 12:15 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >>> > Yes! >>> > >>> > We have Roassal 2 which is pretty well advanced already. We would like >>> to announce Roassal2 the way its deserve: with fireworks and a big fanfare. >>> > >>> > The coming months will be full of surprises. >>> > >>> > Alexandre >>> > >>> > >>> > On Mar 10, 2014, at 9:59 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >>> wrote: >>> > >>> >> Alex, >>> >> >>> >> On 10 Mar 2014, at 13:54, Alexandre Bergel <alexandre.bergel(a)me.com> >>> wrote: >>> >> >>> >>> Yesterday evening I watched the Wolfram video. I think we can >>> produce Pharo-based video as impressive as what this strange guy did. >>> >> >>> >> Please do ! Visualization and marketing is important indeed. >>> >> >>> >> Sven >>> > >>> > -- >>> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> > Alexandre Bergel http://www.bergel.eu >>> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> > >>> > >>> > >>> > >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

March 11, 2014

Re: [Pharo-dev] Bug in valueWithin:onTimeout: ?

by Stefan Marr

Hi ClÃ©ment: On 11 Mar 2014, at 09:58, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Yesterday I had this problem that at startup a pharo image has several process running at priority 40. The problem is that my tests (run from command line) trigger #valueWithin:onTimeout: and the protected block (the block calling #valueWithin:onTimeout:) would always timed out for the first test as resuming the watchdog in #valueWithin:onTimeout: allows another runnable process at the same priority as the active process to be run. > > I'm not very familiar with Pharo's process framework nor with processes in general so I would like to discuss the problem. > > Question 1: Is it a bug ? Just a brief answer: Processes on the same priority are scheduled cooperatively. So, no, it is not a bug. Only processes of different priority are scheduled preemptively. So, it is âby designâ and the expected behavior (which some parts of the system rely on). Best regards Stefan -- Stefan Marr INRIA Lille - Nord Europe http://stefan-marr.de/research/

March 11, 2014

Re: [Pharo-dev] Sort by property

by Yuriy Tymchuk

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

Re: [Pharo-dev] About inspectors

by Guillermo Polito

Doru, for the DBXTalk inspector, maybe it is useful for you this package: http://www.smalltalkhub.com/#!/~DBXTalk/DBXDatabaseModel/ That allows to retrieve database schema metadata in a polymorphic way :) On Tue, Mar 11, 2014 at 7:43 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Thank you. > > In this case yes, it blurs the line between an SQL Editor and the > inspector. And between a table and an Excel code editor. But, here is > another blurred line between the file browser and the inspector: > > http://www.humane-assessment.com/blog/browsing-files-with-gtinspector-video/ > > The GTInspector blurs all sorts of lines and it even empowers you to blur > your own lines :). > > Just a note: the GToolkit is also the work of Andrei. > > Doru > > > On Mon, Mar 10, 2014 at 8:01 PM, Esteban A. Maringolo < > emaringolo(a)gmail.com> wrote: > >> Excellent Tudor! >> >> Very impressive. It blurs the line between a the Smalltalk tools and >> an SQL Editor. >> Esteban A. Maringolo >> >> >> 2014-03-10 12:15 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >> > Yes! >> > >> > We have Roassal 2 which is pretty well advanced already. We would like >> to announce Roassal2 the way its deserve: with fireworks and a big fanfare. >> > >> > The coming months will be full of surprises. >> > >> > Alexandre >> > >> > >> > On Mar 10, 2014, at 9:59 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> > >> >> Alex, >> >> >> >> On 10 Mar 2014, at 13:54, Alexandre Bergel <alexandre.bergel(a)me.com> >> wrote: >> >> >> >>> Yesterday evening I watched the Wolfram video. I think we can produce >> Pharo-based video as impressive as what this strange guy did. >> >> >> >> Please do ! Visualization and marketing is important indeed. >> >> >> >> Sven >> > >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

March 11, 2014

Re: [Pharo-dev] About a Spec dedicated mailing-list

by Nicolai Hess

Are those "+1" meant for "yes a dedicated mailling list" or for sven's " I don't think that makes much sense" comment ? even if you don't want to do something directly with spec (and so, you wouldn't follow that mailinglist), many changes done for spec have an influence on common tools or morphic components. +1 (for svens comment). 2014-03-11 9:02 GMT+01:00 Torsten Bergmann <astares(a)gmx.de>: > +1 > > > Gesendet: Dienstag, 11. MÃ¤rz 2014 um 03:46 Uhr > > Von: "Alexandre Bergel" <alexandre.bergel(a)me.com> > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > Betreff: Re: [Pharo-dev] About a Spec dedicated mailing-list > > > > + 1 > > > > > Le 10-03-2014 Ã 16:48, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > > > > > > Ben, > > > > > > I don't think that makes that much sense (right now): > > > > > > - there is not that much spec specific traffic > > > - spec is a fundamental and critical part of pharo > > > - pharo is a fundamental and critical part of spec > > > - we have to make spec better all together > > > > > > ;-) > > > > > > My 2c, > > > > > > Sven > > > > > >> On 10 Mar 2014, at 18:23, Benjamin < > benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > >> > > >> Hello guys :) > > >> > > >> I was wondering if it will make sense to have a spec dedicated > mailing list :) > > >> As I have pros and cons, I am asking for your opinion :) > > >> > > >> Thanks in advance, > > >> Ben > > > > > > > > > > > >

March 11, 2014