- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ****REALLY IMPORTANT**** the Pharo market place NEEDS YOU

by Esteban Lorenzano

+1 (but AFAIK, versionner can do that) Esteban On 12 Mar 2014, at 11:37, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 12 Mar 2014, at 11:28, jannik laval <jannik.laval(a)gmail.com> wrote: > >> At least, what could be really great is to have the MetaRepo inside the monticello browser, Like that I don't loose time to retrieve the correct url on smalltalkhub and/or ss3. > > +1 > >

March 12, 2014

Re: [Pharo-dev] ****REALLY IMPORTANT**** the Pharo market place NEEDS YOU

by Pharo4Stef

> >> At least, what could be really great is to have the MetaRepo inside the monticello browser, Like that I don't loose time to retrieve the correct url on smalltalkhub and/or ss3. > > +1 I need people to help :)

March 12, 2014

Re: [Pharo-dev] ****REALLY IMPORTANT**** the Pharo market place NEEDS YOU

by Sven Van Caekenberghe

On 12 Mar 2014, at 11:28, jannik laval <jannik.laval(a)gmail.com> wrote: > At least, what could be really great is to have the MetaRepo inside the monticello browser, Like that I don't loose time to retrieve the correct url on smalltalkhub and/or ss3. +1

March 12, 2014

Re: [Pharo-dev] ****REALLY IMPORTANT**** the Pharo market place NEEDS YOU

by jannik laval

Dears, I am using the Catalog for Pharo 2 and 3 for Phratch. My main problem is that when I update my configuration, I have to save it in my repository but also in the MetaRepo. I don't know if an automatic process can be made ? At least, what could be really great is to have the MetaRepo inside the monticello browser, Like that I don't loose time to retrieve the correct url on smalltalkhub and/or ss3. I love this catalog, and I would like to see it always up to date. Cheers, Jannik 2014-03-12 8:29 GMT+01:00 Pharo4Stef <pharo4Stef(a)free.fr>: > Hi guys > > We would like to improve the visibility of Pharo by > - renaming the catalog of published package to marketPlace :) > > - have many more projects decently documented > > Yes click that link: > > https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/ > ? > > So I imagine that you are all like me: you are too busy to add the correct > information > because you do not know what/how/. So I created a little class: called > CatalogAdder for you and me :P > It is available in last version of Versionner but > > I'm a simple utility class that add methods to ConfigurationOf class to > declare catalog metadata. > > Gofer new > smalltalkhubUser: 'DamienCassou' project: 'Pier-Gutemberg'; > package: 'CatalogAdder'; > load. > > (CatalogAdder on: ConfigurationOfXXX) > defineCatalogMetadata > > and it creates all the methods with dummy template for you :) > > Check the catalog* methods and fill them up. > > Stef > > > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/

March 12, 2014

Re: [Pharo-dev] Making Git and Pharo More Accessible

by Goubier Thierry

Le 12/03/2014 11:18, Max Leske a Ã©crit : > > Will do. Thanks, Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

March 12, 2014

Re: [Pharo-dev] Sort by property

by carlo.t

Hi Otto I think the main reason is to support the second usage scenario: SequenceableCollection withAllSubclasses sortedAs: [:class | class methodDict size]. We could try and unify the sort: method to take only blocks while sortedAs: a symbol but then at the same time we could just put everything into one method and use cull: perhaps to handle all the scenarios. Personally I donât feel too comfortable with the code below, apart from the performance penalties it also feels like code that is too âcleverâ for itself which obviously makes it complicated to understand and modify. I wrote it mainly for people to voice opinions and get ideas flowing. Iâd have 2 separate sort methods so that users can choose if they want the runtime characteristics of either. Example which can handle all current scenarios i.e. symbol or block taking 1 or 2 arguments: SequenceableCollection>>sort: aSortBlock self mergeSortFrom: 1 to: self size by: (self createSortBlock: aSortBlock) SequenceableCollection>>createSortBlock: aSortBlockOrSymbol ^ aSortBlockOrSymbol numArgs < 2 ifTrue: [[ :a :b | (#(true false ) includes: (aSortBlockOrSymbol value: a)) ifTrue: [ aSortBlockOrSymbol value: a] ifFalse: [(aSortBlockOrSymbol value: a) < (aSortBlockOrSymbol value: b)]]] ifFalse: [[:a :b | aSortBlockOrSymbol cull: a cull: b]] BTW the previous versions had a bug where it fails when called on an empty collection as the true/false check is done eagerly. Cheers Carlo -- View this message in context: http://forum.world.st/Sort-by-property-tp4748500p4748757.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 12, 2014

Re: [Pharo-dev] Making Git and Pharo More Accessible

by Max Leske

On 12.03.2014, at 09:20, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 12/03/2014 08:12, Max Leske a Ã©crit : >> Hi Sean >> >> Iâm in Lille at the moment where weâve set up a plan of action for Git yesterday. I will be working with the guys from RMoD for the next two weeks and hope that by the end we can unify all the different workflows that currently exist to something that we can all more or less agree on. >> >> I donât think it makes sense to set up a CI job for only two weeks, so youâll have to be patient a little longer (unless someone else feels that it *does* make sense and creates a job nonetheless :) ). > > Hi Max, > > Please keep us posted about the progress so that we're able to coordinate and integrate. For now, all options apart from mine are visible to me as: 'will be ready in the future' (but that was also the case more than a year ago). Will do. > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

March 12, 2014

Re: [Pharo-dev] Touch Events VM changes

by Pharo4Stef

On 12 Mar 2014, at 10:27, J.F. Rick <self(a)je77.com> wrote: > Does that mean that normal mouse movement won't work with that VM? I have a couple other things that take precedent but that does sound like it would be worth playing with. What igor and ronie did is to remove the events support from the VM but use NativeBoost to get the OS events. > > Cheers, > > Jeff > > > On Tue, Mar 11, 2014 at 1:29 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Jeff, since you running linux you can look at what we have done with Ronie not long ago. > Basically we changed VM and removed all window/event management code and instead do everything at image side. > I think it would be good if you can try and add multi-touch events support to the code. > > If you wanna try, you need to build new VM first, > and follow this: > https://pharo.fogbugz.com/f/cases/12743/OSWindow-integration > > Then you can look at OSWindow package (its X11 part) and see what is needed to support multi-touch events. > > You should build VM from sources taken from here: > https://github.com/ronsaldo/pharo-vm > > > > On 11 March 2014 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 > > > > -- > Best regards, > Igor Stasenko. > > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick

March 12, 2014

Re: [Pharo-dev] Making Git and Pharo More Accessible

by Stephan Eggermont

Max wrote: >I donât think it makes sense to set up a CI job for only two weeks, so youâll have to be patient a little longer (unless someone >else feels that it *does* make sense and creates a job nonetheless :) ). I do. It takes about 5 minutes to set up a job, it provides documentation of what needs to be done, and it allows people outside Lille to follow what happens. (Making the job do the right things of course takes a bit longer if you need to do more than load a configuration (like compiling a vm with a git library plugin)). Stephan

March 12, 2014

Re: [Pharo-dev] [ANN] RenoirSt 1.0.0 Release for Pharo 3.0

by Stephan Eggermont

Stef wrote > for what is the px unit stand for? (from tex.stackexchange) >From the plain TeX reference: â¢ pt: Point â¢ pc: pica (12 pt) â¢ in: inch (72.27 pt) â¢ bp: Big point (72 bp = 1 in) â¢ cm: Centimeter â¢ mm: Millimeter â¢ dd: Didot point â¢ cc: cicero (12 dd) â¢ sp: Scaled point (65536 sp = 1 pt), the smallest TeX unit â¢ ex: Nominal x-height â¢ em: Nominal m-width Available in math mode: â¢ mu: math unit, 1 em = 18 mu, where em is taken from the math symbols family, various lengths are derived from it (thinspace, thickspace, etc.) Additionally available in pdfTeX and LuaTeX: â¢ px: "pixel", the dimension given to the \pdfpxdimen primitive; default value is 1 bp, corresponding to a pixel density of 72 dpi Stephan

March 12, 2014