[Pharo-users] Pharo 8 64 bit image fails to launch
--- Begin Message ---
I just downloaded Pharo Launcher and downloaded Pharo 8.0 - 64bit (Stable)
I created an image but when I try to run it, I see the below Console entries
and the process disappears.
Im running Catalina on a MacBookPro.
Console filter : Pharo
default 12:45:28.183485-0600hiddConnection removed:
IOHIDEventSystemConnection uuid:7B1A1A94-63A2-47C7-BCA6-BCC1D2EB629A pid:44235
process:Pharo type:Passive entitlements:0x0 caller:HIServices:
___GetIOHIDEventSystemClient_block_invoke + 26 attributes:(null) inactive:1
events:0 mask:0x0
default 12:45:28.185375-0600kernel AGC:: [Pharo pid 44235 non-mux-aware]
exiting, non-mux-aware app count 0, runtime: 0:46:40.238
default 12:45:28.185501-0600kernel AGC:: [Pharo pid 44235 mux-aware]
exiting, non-mux-aware app count 0, runtime: 0:46:40.239
default 12:45:28.185340-0600hiddConnection removed:
IOHIDEventSystemConnection uuid:12E9BB2B-2602-4885-8303-33C1285F8AA7 pid:44235
process:Pharo type:Passive entitlements:0x0 caller:HIToolbox:
___GetIOHIDEventSystemClient_block_invoke + 26 attributes:(null) inactive:1
events:0 mask:0x0
default 12:45:28.192573-0600runningboardd Invalidating assertion
398-200-7609 (target:executable) from originator 200
default 12:45:28.206986-0600mDNSResponder [R75091]
DNSServiceCreateConnection STOP PID[44235](Pharo)
default 12:45:28.206883-0600runningboardd [executable:44235]
Death sentinel fired!
default 12:45:28.218215-0600loginwindow -[PersistentAppsSupport
applicationQuit:] | for app:PharoLauncher, _appTrackingState = 2
default 12:45:28.218254-0600loginwindow -[PersistentAppsSupport
applicationQuit:] | App: PharoLauncher, quit, updating active tracking timer
default 12:45:28.221573-0600runningboardd Invalidating assertion
398-200-7463 (target:executable) from originator 200
default 12:45:28.295074-0600runningboardd [executable:44235]
Ignoring jetsam update because this process is not memory-managed
default 12:45:28.295213-0600runningboardd [executable:44235]
Ignoring suspend because this process is not lifecycle managed
default 12:45:28.295401-0600runningboardd [executable:44235]
Ignoring GPU update because this process is not GPU managed
default 12:45:28.308173-0600runningboardd Removing process:
[executable:44235]
default 12:45:28.315872-0600runningboardd Removing assertions for
terminated process: [executable:44235]
default 12:45:30.214210-0600Finder Requested application has
policy 0, associated category:DH1009 associated sites:(null) equivalent bundle
identifiers:org.pharo.PharoLauncher
default 12:45:30.755403-0600Finder Requested application has
policy 0, associated category:DH1009 associated sites:(null) equivalent bundle
identifiers:org.pharo.PharoLauncher
default 12:45:33.211384-0600NotificationCenter Looking up app info for
org.pharo.PharoLauncher
default 12:45:33.218892-0600NotificationCenter Found info for
org.pharo.PharoLauncher at . app name:
default 12:45:33.220539-0600loginwindow -[PersistentAppsSupport
saveLogoutPersistentState:finalSnapshot:] | previouslyRunningApps: (
{
BackgroundState = 2;
BundleID = "com.apple.safari";
Hide = 0;
Path = "/Applications/Safari.app";
},
{
BackgroundState = 2;
BundleID = "com.apple.finder";
Hide = 0;
Path = "/System/Library/CoreServices/Finder.app";
},
{
BackgroundState = 2;
BundleID = "com.apple.mail";
Hide = 0;
Path = "/System/Applications/Mail.app";
},
{
BackgroundState = 2;
BundleID = "org.pharo.pharolauncher";
Hide = 0;
Path = "/Applications/PharoLauncher.app";
},
{
BackgroundState = 2;
BundleID = "com.apple.systempreferences";
Hide = 0;
Path = "/System/Applications/System Preferences.app";
},
{
BackgroundState = 2;
BundleID = "com.apple.console";
Hide = 0;
Path = "/System/Applications/Utilities/Console.app";
},
{
BackgroundState = 2;
BundleID = "com.apple.activitymonitor";
Hide = 0;
Path = "/System/Applications/Utilities/Activity Monitor.app";
},
{
BackgroundState = 2;
BundleID = "com.agilebits.onepassword4";
Hide = 0;
Path = "/Applications/others/ accounting&records/1Password 6.app";
},
{
BackgroundState = 2;
BundleID = "com.apple.terminal";
Hide = 0;
Path = "/System/Applications/Utilities/Terminal.app";
},
{
BackgroundState = 3;
BundleID = "org.macosforge.xquartz.x11";
Hide = 0;
Path = "/Applications/Utilities/XQuartz.app";
},
{
BackgroundState = 2;
BundleID = "com.electron.kitematic_(beta)";
Hide = 0;
Path = "/Applications/Kitemat
Re: [Pharo-users] "Theming" dictionaries?
On 19/02/20 12:15 p. m., Esteban Maringolo wrote: > On Wed, Feb 19, 2020 at 2:09 PM Richard Sargent > wrote: > >> If you want to have a limited API, you wrap a dictionary with a new class >> that exposes just the API you desire consumers to use. >> >> In general, inheritance is often overused or/ misused. Composition is >> usually a better technique unless you want the full API of the hierarchy to >> be available and used. > +1 to this. > > Inheriting means accepting the "interface contract" of being able to > respond to all the messages understood by its superclasses. > It also limits your model to future refactorings and modifications. > > I rarely, if ever, sub-classify any "base" class for domain modelling, > and more so in the case of Collection classes, and when I had to deal > with domain classes that did that, it always caused more problems than > solutions. > > Regards, > > Esteban A. Maringolo > Thanks for all your answers in the thread. I think that I see how this can be done now. Cheers, Offray
Re: [Pharo-users] "Theming" dictionaries?
On Wed, Feb 19, 2020 at 2:09 PM Richard Sargent wrote: > If you want to have a limited API, you wrap a dictionary with a new class > that exposes just the API you desire consumers to use. > > In general, inheritance is often overused or/ misused. Composition is usually > a better technique unless you want the full API of the hierarchy to be > available and used. +1 to this. Inheriting means accepting the "interface contract" of being able to respond to all the messages understood by its superclasses. It also limits your model to future refactorings and modifications. I rarely, if ever, sub-classify any "base" class for domain modelling, and more so in the case of Collection classes, and when I had to deal with domain classes that did that, it always caused more problems than solutions. Regards, Esteban A. Maringolo
Re: [Pharo-users] "Theming" dictionaries?
See below. On Wed, Feb 19, 2020 at 8:49 AM Offray Vladimir Luna Cárdenas < offray.l...@mutabit.com> wrote: > Hi, > > As some of you may know, I'm a "savage coder" who learned > Smalltalk/Pharo by himself, of course thanks to communities, books and > videos, but without formal training or peers in the same country and > guided mostly by necessity. All this to say that this maybe kind of a > silly question. > > Anyway, we have this project called Minipedia[1], that imports Wikipedia > articles and their history. A Minipedia language there, is just a > dictionary, where the key is the language two letters code and the value > for each key is an array of article titles. There is any way to > specialize a Dictionary to tell it, name your 'key' as language and your > 'value' as 'titles'? > There are several ways, depending on your intention. If you intend that the full Dictionary and Collection API is available to all the places where this artefact will be used, you can add extensions to the Dictionary class to provide alias accessing methods or you can also subclass Dictionary and only have your aliases (and whatever API) visible only to consumers of that class. The former is a quick and dirty approach. The latter is better, since every Dictionary is NOT a language keyed collection of article. If you want to have a limited API, you wrap a dictionary with a new class that exposes just the API you desire consumers to use. In general, inheritance is often overused or/ misused. Composition is usually a better technique unless you want the full API of the hierarchy to be available and used. > [1] https://mutabit.com/repos.fossil/minipedia/ > > Thanks, > > Offray > > > >
Re: [Pharo-users] "Theming" dictionaries?
I'm not sure I fully understand your question. But Dictionaries expect its elements to respond to #key/#value messages, and in the case of Pharo Dictionary is tightly bound to the Association class (and the #-> selector), so there is no way to subclassify Dictionary and specify the class of its elements. Otherwise you could subclassify Dictionary and have its elements to be instances of "MinipediaLanguage", that is polymorphic with Association but have language/titles instead of key/value. I don't see the need for it, though. Esteban A. Maringolo On Wed, Feb 19, 2020 at 1:49 PM Offray Vladimir Luna Cárdenas < offray.l...@mutabit.com> wrote: > Hi, > > As some of you may know, I'm a "savage coder" who learned > Smalltalk/Pharo by himself, of course thanks to communities, books and > videos, but without formal training or peers in the same country and > guided mostly by necessity. All this to say that this maybe kind of a > silly question. > > Anyway, we have this project called Minipedia[1], that imports Wikipedia > articles and their history. A Minipedia language there, is just a > dictionary, where the key is the language two letters code and the value > for each key is an array of article titles. There is any way to > specialize a Dictionary to tell it, name your 'key' as language and your > 'value' as 'titles'? > > [1] https://mutabit.com/repos.fossil/minipedia/ > > Thanks, > > Offray > > > >
[Pharo-users] "Theming" dictionaries?
Hi, As some of you may know, I'm a "savage coder" who learned Smalltalk/Pharo by himself, of course thanks to communities, books and videos, but without formal training or peers in the same country and guided mostly by necessity. All this to say that this maybe kind of a silly question. Anyway, we have this project called Minipedia[1], that imports Wikipedia articles and their history. A Minipedia language there, is just a dictionary, where the key is the language two letters code and the value for each key is an array of article titles. There is any way to specialize a Dictionary to tell it, name your 'key' as language and your 'value' as 'titles'? [1] https://mutabit.com/repos.fossil/minipedia/ Thanks, Offray
Re: [Pharo-users] Hi-DPI Support
--- Begin Message --- For the mouse pointer, if you're on Windows, you can have a look at VistaCursor Metacello new repository: 'github://astares/Pharo-VistaCursors/src'; baseline: 'VistaCursors'; load It has scale factor available in the settings application. Renaud Feb. 18, 2020, 11:43 by wild.id...@gmail.com: > I'm also looking forward to Hi-DPI support being fully implemented in Pharo. > > Until then, there is the "Display scale factor" slider and the ability to > change the font size. However, most have probably already noticed that > these controls don't affect the size of the mouse pointer, which can be > annoying as it's much harder to find on big screens. > > I recently found this posting, which is helpful: > > Scaling for HiDPI in Pharo: > 1.) Evaluating "MenubarMorph reset" will fix the menu bar scaling factor. > 2.) There's a SQUEAK_FAKEBIGCURSOR env var which you can set to 1 to have > the VM > display the cursor twice as big as normal. I've no idea why the word 'FAKE' > is > part of this; from the source it looks like it just creates a normal X11 > cursor > that's twice as big as normal. This should work with Cuis, Squeak, and > Pharo, > as it's part of the VM. > > I found that entering "export SQUEAK_FAKEBIGCURSOR=1" will cause standalone > Pharo to have a normal-looking pointer on 4K displays, but this does not > seem to work as expected with Pharo Launcher, or images launched with Pharo > Launcher. > > After some investigation, I determined that the 'pharo-launcher', 'pharo' > and 'pharo-ui' bash scripts (for Pharo Launcher and Pharo IOT) can be > modified to make this work. > > The trick is to add "env SQUEAK_FAKEBIGCURSOR=1" to the front of the command > that launches the VM/image within the above scripts. > > I've fashioned a set of 'sed' one-liners to automate editing these scripts > accordingly, and am in the process of making a bash script that will use > them to add/remove/verify these edits in a user-friendly fashion. (I also > have scripts that install Pharo Launcher and Pharo IOT in Linux, that create > & add clickable launcher icons; my plan was to modify these scripts to write > the cursor size correction scripts into their respective folders when > they're installed.) > > I'll make this available when it's complete, likely in the next couple of > days. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > --- End Message ---
