September 2018 - Pharo-users

TextEditor

by Hilaire

Hello, How can I get a text editor window? I can't make sense of the TextEditor class, and its comment is not helpful. What is the logic behind? Thanks Hilaire -- Dr. Geo http://drgeo.eu

Sept. 20, 2018

A mentoring course ComplexCondition implementation

by Vitor Medina Cruz

Hello, In A Mentoring Course in Smalltalk, Andr es Valloud explains a really good implementation of and API to deal with complex conditions, is there any implementation of this (or similar) on Pharo? Regards, Vitor

Sept. 20, 2018

Re: [Pharo-users] Distinguishing between dynamic vs. static HTTP requests

by Sven Van Caekenberghe

Hmm, not really, in Seaside it is typically /files and /static is something that I have used as well, but really it should be flexible as there are too many different scenarios, including all kinds of prefixes. > On 20 Sep 2018, at 09:49, James Foster <Smalltalk(a)JGFoster.net> wrote: > > When serving web pages from a web server in front of Smalltalk (e.g., Apache, Nginx, etc.), is there a convention for designating which pages are to be sent on to Smalltalk and which are to be served directly (or sent somewhere else)? Is there a prefix or suffix for one or the other? That is, do you treat everything that begins with â/static/â as static (easy enough) and everything else gets forwarded to Smalltalk? Or do you have a similar prefix for â/dynamic/â content? Or do you have a suffix (â.stâ or â.seasideâ) that designates requests that are sent on to Smalltalk? I can make any of these work, and I can come up with my own rules, but if there is a convention Iâd like to follow it. > > Thanks, > James

Sept. 20, 2018

Distinguishing between dynamic vs. static HTTP requests

by James Foster

When serving web pages from a web server in front of Smalltalk (e.g., Apache, Nginx, etc.), is there a convention for designating which pages are to be sent on to Smalltalk and which are to be served directly (or sent somewhere else)? Is there a prefix or suffix for one or the other? That is, do you treat everything that begins with â/static/â as static (easy enough) and everything else gets forwarded to Smalltalk? Or do you have a similar prefix for â/dynamic/â content? Or do you have a suffix (â.stâ or â.seasideâ) that designates requests that are sent on to Smalltalk? I can make any of these work, and I can come up with my own rules, but if there is a convention Iâd like to follow it. Thanks, James

Sept. 20, 2018

Re: [Pharo-users] Retina support in Pharo

by Alexandre Bergel

Hi Andy, I have not idea. But this would be a very valuable effort. Cheers, Alexandre > On Sep 18, 2018, at 5:12 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. 20, 2018

Re: [Pharo-users] Calypso and critiques (Pharo7)

by Arturo Zambrano

Oh! I found this ... sorry for asking a reported problem ClyCriticBrowserPlugin disable.ClyCriticEnvironmentPlugin disable.ClyNavigationEnvironment reset. On Wed, Sep 19, 2018 at 1:26 PM Arturo Zambrano <arturo.zambrano(a)gmail.com> wrote: > Hi all, > is there any way to switch off the critiques pane in the bottom of > calypso? > > Thanks ! >

Sept. 19, 2018

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