- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo 4.0 - display

by MartinW

recursive wrote > This is probably already a potential known solution to the display issue > on > MAC Retina displays but I've just tried the latest CogVM with the Pharo > 4.0 > image and using Cog fixes the issue, it no longer leaves outlines of > windows or tracers. No, this is just because Cog defaults to "Open in low resolution" and Pharo VM does not. You can start Pharo VM in low resolution and then you do not have the artefacts. This might be a short term workaround. But the goal would be to have retina support for Pharo :) <http://forum.world.st/file/n4822030/Cog_low_resolution.jpg> -- View this message in context: http://forum.world.st/Pharo-4-0-display-tp4821797p4822030.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 26, 2015

[NB] NBExternalArray not working for complex types?

by Max Leske

Hi guys I have a problem with NBExternalArray. AFAICT the generated assembly should be able to handle arbitrary elements in the array (as long as they are all of the same type). The operations required to read / write an element are given by the external type specified for the collection (e.g âcharâ or âintâ). All of this works wonderfully for char, int, NBExternalAddress etc. But Iâm trying to get it working for strings. So here is the code that I would expect to work: arrayClass := NBExternalArray anonymousSubclassInitElementType: 'String'. array := arrayClass new: 1. array at: 1 put: âfoo'. array at: 1. ââ> should procude âfooâ, but produces arbitrary stringsâ I can make it work with NBExternalAddress of course but I donât want to if I can avoid it. Iâd appreciate it if someone (Nicolai?) could take a look at NBExternalArray>>emitRead / emitWrite and see if thereâs an easy solution. Especially for strings I donât think it should be too hard since all thatâs needed is already present in the string handling facilities. Cheers, Max

April 26, 2015

Re: [Pharo-dev] SystemWindow vs. StandardWindow

by stepharo

I love your state of mind. Take Pharo 30 and look at Menu API. I definitively wants to shrink it to the correct size. :) Le 26/4/15 03:51, Ben Coman a Ã©crit : > +1... > > * Outside of Pharo, I've only ever know it be called a "window title". > Never heard of "window label". A "label" would be for panes, tabs > and widgets within the window. > > * Historical context + implementor-count... > * StandardWindow>>title: ~2006 +25-most-window-related > * StandardWindow>>title ~2006 +170 (most return constant > strings - window related?) > * SystemWindow>>label ~1998 +370-many-unrelated-to-windows > * SystemWindow>>setLabel: ~2011 +1 > > * Not sure how useful it is, but I compiled a table for comparison > https://docs.google.com/spreadsheets/d/1YvMgH8uSbOsSf30T7lyaCCcnDLy4tzXnM39… > > * Would need to consider the 8 methods of SystemWindow "label" protocol > > * One random observation > EyeCollectionInspector>>title and EyeCollectionInspector-class>>label > > cheers -ben > > > On Fri, Apr 24, 2015 at 10:53 PM, Sean P. DeNigris > <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: > > Is this distinction necessary? > > I started digging when I noticed that SystemWindow>>#label and > #setLabel: > becomes StandardWindow>>#title and #title. Wouldn't it be better > to just > push #title up if we like that API better? It's exhausting to > manage all > these tiny (and possibly unnecessary) differences... > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/SystemWindow-vs-StandardWindow-tp4821655.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 26, 2015

Re: [Pharo-dev] brickValue: in Glamour-Morphic-Brick

by stepharo

> > Not really, it is implemented also in Object. > It is used to script brick layout properties. So user can say: > > brick height: 10. > brick height: #approximate. brick height: [ :b | b width * 2]. while I can see that this too cases are similar, sending value to any object is always to me over polymorphism. If we could not extend Object, the provider could simply add value in his class? We are always trying to remove messages from Object. > or even > > brick height: HeightStrategy new. > > so brickValue: is sent to any kind of object that is used as height. > So without changing brick itself user can implement its own class and > override brickValue: and have custom strategy to calculate height. > > Such practice is used in many places in brick. > > > > Cheers, > Alex > > On Sun, Apr 26, 2015 at 12:16 AM, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > Can we remove #brickValue: ? > I don't see how this is different from #cull: > And the name is strange, I don't see how this depends an a brick. > > nicolai > >

April 26, 2015

Re: [Pharo-dev] Pharo configurations via git unloadable behind proxy

by Thierry Goubier

Le 26 avr. 2015 16:50, "Sven Van Caekenberghe" <sven(a)stfx.eu> a Ã©crit : > > Pharo only knows about HTTP proxies, not proxies for any other protocol. In uko's example, protocol is filetree over http (github URLs). I would suggest trying to set the proxy inside pharo. Thierry > > > On 26 Apr 2015, at 16:42, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: > > > >> > >> Am 26.04.2015 um 16:36 schrieb Max Leske <maxleske(a)gmail.com>: > >> > >> > >>> On 26 Apr 2015, at 15:42, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: > >>> > >>> Trying to load a configuration that involves git (eg. QualityAssistant) with the configuration browser fails if I am behind a proxy while others (without git) work fine. > >>> Do I miss a configuration for git? > >> > >> What exactly fails? Do you get an exception? Is it a connection problem? > > The contents of downloaded files (eg. github-UkoQualityAssistantv041531859342567419945494505101053.zip) is > > just > > > > <HTML></HTML> > > > > and thus decompressing fails. > > This problem is reproducible behind a proxy and works without a proxy. Other configurations (e.g. NoCSV) work properly behind the proxy. > >

April 26, 2015

Re: [Pharo-dev] Pharo configurations via git unloadable behind proxy

by Sven Van Caekenberghe

Pharo only knows about HTTP proxies, not proxies for any other protocol. > On 26 Apr 2015, at 16:42, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: > >> >> Am 26.04.2015 um 16:36 schrieb Max Leske <maxleske(a)gmail.com>: >> >> >>> On 26 Apr 2015, at 15:42, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: >>> >>> Trying to load a configuration that involves git (eg. QualityAssistant) with the configuration browser fails if I am behind a proxy while others (without git) work fine. >>> Do I miss a configuration for git? >> >> What exactly fails? Do you get an exception? Is it a connection problem? > The contents of downloaded files (eg. github-UkoQualityAssistantv041531859342567419945494505101053.zip) is > just > > <HTML></HTML> > > and thus decompressing fails. > This problem is reproducible behind a proxy and works without a proxy. Other configurations (e.g. NoCSV) work properly behind the proxy.

April 26, 2015

Re: [Pharo-dev] Pharo configurations via git unloadable behind proxy

by Andreas Wacknitz

> Am 26.04.2015 um 16:36 schrieb Max Leske <maxleske(a)gmail.com>: > > >> On 26 Apr 2015, at 15:42, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: >> >> Trying to load a configuration that involves git (eg. QualityAssistant) with the configuration browser fails if I am behind a proxy while others (without git) work fine. >> Do I miss a configuration for git? > > What exactly fails? Do you get an exception? Is it a connection problem? The contents of downloaded files (eg. github-UkoQualityAssistantv041531859342567419945494505101053.zip) is just <HTML></HTML> and thus decompressing fails. This problem is reproducible behind a proxy and works without a proxy. Other configurations (e.g. NoCSV) work properly behind the proxy.

April 26, 2015

Re: [Pharo-dev] brickValue: in Glamour-Morphic-Brick

by Nicolai Hess

2015-04-26 1:35 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > Can we remove #brickValue: ? >> I don't see how this is different from #cull: >> And the name is strange, I don't see how this depends an a brick. > > > Not really, it is implemented also in Object. > Ah, ok, I missed that one. > It is used to script brick layout properties. So user can say: > > brick height: 10. > brick height: #approximate. > brick height: [ :b | b width * 2]. > > or even > > brick height: HeightStrategy new. > > so brickValue: is sent to any kind of object that is used as height. So > without changing brick itself user can implement its own class and override > brickValue: and have custom strategy to calculate height. > > Such practice is used in many places in brick. > > I saw the call to brickValue: in GTSpotter and GLMAnimation, is it only used for brick attributes, like in your example above? nicolai > > > Cheers, > Alex > > On Sun, Apr 26, 2015 at 12:16 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Can we remove #brickValue: ? >> I don't see how this is different from #cull: >> And the name is strange, I don't see how this depends an a brick. >> >> nicolai >> > >

April 26, 2015

Re: [Pharo-dev] Pharo configurations via git unloadable behind proxy

by Max Leske

> On 26 Apr 2015, at 15:42, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: > > Trying to load a configuration that involves git (eg. QualityAssistant) with the configuration browser fails if I am behind a proxy while others (without git) work fine. > Do I miss a configuration for git? What exactly fails? Do you get an exception? Is it a connection problem? > > Regards > Andreas > >

April 26, 2015

Pharo configurations via git unloadable behind proxy

by Andreas Wacknitz

Trying to load a configuration that involves git (eg. QualityAssistant) with the configuration browser fails if I am behind a proxy while others (without git) work fine. Do I miss a configuration for git? Regards Andreas

April 26, 2015