- Pharo-users - lists.pharo.org

Calypso and critiques (Pharo7)

by Arturo Zambrano

Hi all, is there any way to switch off the critiques pane in the bottom of calypso? Thanks !

Sept. 19, 2018

Re: [Pharo-users] Yet another Pharo in docker

by Herbert VojÄÃk

Updated with 60543 release of 6.1, now that zeroconf (used to build this) contains newer vm. Herby P.S.: Not used the official one yet, if it proves to be composable enough, I'd gladly abandon this one. Herbert VojÄÃk wrote on 27. 6. 2018 20:27: > Updated with 60541 release of 6.1. > > Herby VojÄÃk wrote on 18. 10. 2017 22:17: >> Herby VojÄÃk wrote: >>> https://hub.docker.com/r/herbysk/pharo/ >>> >> Thanks to gotchas@dockerhub whose scripts I adapted. >> >

Sept. 18, 2018

Re: [Pharo-users] Retina support in Pharo

by Dimitris Chloupis

I may be wrong but last time I checked access to the OS Graphics API was handled by the VM itself. There was a talk about decoupling that from the VM and porting it to the image but no idea if it happened. if it was the pragma primitive inside the method that means it calls native code , the second case is using the UFFI which is the official FFI of Pharo. The Pragma needs a VM rebuild , the UFFI does not. These are the two ways that Pharo intefaces with native code (C/ObjectiveC etc). So for starters you are going to need the VMMaker which is responsible for building the VM , the good news is that it retains a lot of the live coding characteristics and can even compile smalltalk to C (Slang) which is how it keeps most of the code in Smalltalk rather than C. If the Graphics API is still inside the VM then Eliot and other contributors will be able to point you at the VM mailing list at the right direction. If it is not then pharo-dev mailing list will most likely have the developer/s responsible for porting it to the image and they will also be able to point you to the right direction. I dont think experience in smalltalk would play a big role here mainly because its a C problem than a Smalltalk problem cause those libraries that offer Retina support are written and meant to be used by C (ObjC) , this applies for both primitive pragmas and UFFI. You experience with Cocoa is going to be the crucial factor here, if you know how to do it in C , doing it in Smalltalk is relative easy. You may also be able to pintpoint the methods responsible for the rendering by inserting a breakpoint in a window's draw method. The debugger should be able to give you the stack back to the primitive/uffi call. Of course it will require a bit of navigating around but such is the nature and curse of coding. On Tue, Sep 18, 2018 at 11:13 AM andyl <andylarder(a)hotmail.com> wrote: > Hi, > > Has any work been done of this? If not, could someone point me in the right > direction to start it, perhaps with a list of what is already known about > the issue? I'd be willing to look at both MacOS and Windows HiDPI rendering > at the same time. > > Presumably the 64 bit MacOS build is Cocoa based, so that would be the > right > starting point? > > Although I have decades of experience of the above platforms, I'm a > relative > novice with the Smalltalk libraries - so any hints as to how the rendering > process currently hangs together (and how much is Smalltalk vs native > rendering) would be really helpful. > > Regards, > Andy. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Sept. 18, 2018

Re: [Pharo-users] Retina support in Pharo

by andyl

Hi, Has any work been done of this? If not, could someone point me in the right direction to start it, perhaps with a list of what is already known about the issue? I'd be willing to look at both MacOS and Windows HiDPI rendering at the same time. Presumably the 64 bit MacOS build is Cocoa based, so that would be the right starting point? Although I have decades of experience of the above platforms, I'm a relative novice with the Smalltalk libraries - so any hints as to how the rendering process currently hangs together (and how much is Smalltalk vs native rendering) would be really helpful. Regards, Andy. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 18, 2018

Re: [Pharo-users] To get started with Gtoolkit and bloc

by Hilaire

Thanks for the example and the article. How do you know to start with #draggableInParent? I will look more deeply at the links you gave. I like the story telling in your screenshot. This gives inspiration to apply to other domain. Hilaire Le 17/09/2018 Ã 09:02, Tudor Girba a Ã©critÂ : > > I see where the issue comes from. > > The <gtExample> are like test methods that return an object. That > object serves as example, but it is not necessarily a user facing object. > > Look at the picture below showingÂ BlDragExamples>>#draggableInParent. -- Dr. Geo http://drgeo.eu

Sept. 17, 2018

Re: [Pharo-users] [ANN] New Pharo 6.1 stable VM

by Esteban Lorenzano

> On 17 Sep 2018, at 16:45, Petr Fischer via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > From: Petr Fischer <petr.fischer(a)me.com> > Subject: Re: [Pharo-users] [ANN] New Pharo 6.1 stable VM > Date: 17 September 2018 at 16:45:16 CEST > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > > Is new VM here? > > https://files.pharo.org/vm/pharo-spur64/linux/ <https://files.pharo.org/vm/pharo-spur64/linux/> The now stable VM for Pharo 6.1 was always there. What âpromote to stableâ means is that I put a link in the official place to download the VM: https://files.pharo.org/get-files/61 <https://files.pharo.org/get-files/61>, and now is what you get with zeroconf. Esteban > > Thanks, pf > > >> Hi, >> >> Following what I had in my todo list for when coming back from ESUG, I promoted a new stable VM for Pharo 6.1. >> This is the VM that has been tested during almost two months for Pharo 7.0, so it should be fine, but let me know if there is any problem. >> >> Esteban > > >

Sept. 17, 2018

Re: [Pharo-users] [Demo] Creating Bloc Widgets in Pharo

by Hilaire

Thanks for sharing Hilaire Le 16/09/2018 Ã 21:08, stephan a Ã©critÂ : > Bloc has improved a lot in the past year. It is ready for your > experiments. Here is one of mine: > > https://github.com/StephanEggermont/Presentations -- Dr. Geo http://drgeo.eu

Sept. 17, 2018

Re: [Pharo-users] is class-side name setter used by the system

by Marcus Denker

> On 17 Sep 2018, at 16:23, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 17 Sep 2018, at 10:17, tesonep(a)gmail.com <mailto:tesonep@gmail.com> wrote: >> >> Hi Peter, >> there is no more #name: in Class (or ClassDescription or Behavior). It is named #setName: >> It is only used by the class builder, some class methods and some tests. It could be hidden better if it is still a problem. >> > > yes, we should deprecate name: and only use setName: (that is what it used to be originally anyway) ah, yes, in Pharo7 this is already done. Just setName: is there, no #name: Marcus

Sept. 17, 2018

Re: [Pharo-users] [ANN] New Pharo 6.1 stable VM

by Petr Fischer

Is new VM here? https://files.pharo.org/vm/pharo-spur64/linux/ Thanks, pf > Hi, > > Following what I had in my todo list for when coming back from ESUG, I promoted a new stable VM for Pharo 6.1. > This is the VM that has been tested during almost two months for Pharo 7.0, so it should be fine, but let me know if there is any problem. > > Esteban

Sept. 17, 2018

Re: [Pharo-users] is class-side name setter used by the system

by Marcus Denker

> On 17 Sep 2018, at 10:17, tesonep(a)gmail.com wrote: > > Hi Peter, > there is no more #name: in Class (or ClassDescription or Behavior). It is named #setName: > It is only used by the class builder, some class methods and some tests. It could be hidden better if it is still a problem. > yes, we should deprecate name: and only use setName: (that is what it used to be originally anyway) > Cheers. > > > On Mon, Sep 17, 2018 at 9:57 AM Peter Uhnak <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > Hi, > > is the class-side "name:" setter used by the system itself? > Because I remember many times overriding it for my own needs and it never broke anything as far as I know... which makes it strange why it even exists (because it is a trap). > > Thanks, > Peter > > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com>

Sept. 17, 2018