October 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About icon: and iconNamed:

by stepharo

Le 12/10/16 Ã 14:28, Denis Kudriashov a Ã©crit : > Hi Stef. > > It is really good idea. And it makes me think why we ask users for > real icon Form and not just name? > > We could say any component which shows icons should be created with > concrete ThemeIcons ("Smalltalk ui icons" by default) to retrieve > actual form by name. And users should always specify icon names > instead of forms. I think that tools should be parametrized with an icon provider object. Stef > > What you think? > > > 2016-10-12 13:25 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > Hi glamourers and other > > Hi > > I'm currently enhancing the API of Settings to propose to the > users to pass not an icon but an icon named so that all the > clients are not force to use. See below. > > Now it would be great if Glamour could do the same. > > Doru and Andrei? > > > menuOn: aBuilder > "Specify the menu used when writing text." > <contextMenu> > <RubLineNumberMenu> > (aBuilder item: #'Find...' translated) > keyText: 'f'; > selector: #find; > icon: (Smalltalk ui icons iconNamed: #smallFindIcon) > > ====> > > menuOn: aBuilder > "Specify the menu used when writing text." > <contextMenu> > <RubLineNumberMenu> > (aBuilder item: #'Find...' translated) > keyText: 'f'; > selector: #find; > iconNamed: #smallFindIcon > > > Stef > > > >

Oct. 12, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Denis Kudriashov

2016-10-12 15:01 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > Because ThemeIcons may not be the only place from which you draw icons, > and because programming with strings doesn't scale. > It is not programming with strings. Most users of icons (I really think all of them) are only specify name and really don't care how retrieve them.

Oct. 12, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Peter Uhnak

Also regarding `#smallFindIcon asIcon`, there are many places where we can enter icons (e.g. Spec), so once we make a choice for Settings we should modify it there too. Peter On Wed, Oct 12, 2016 at 03:01:26PM +0200, Peter Uhnak wrote: > On Wed, Oct 12, 2016 at 02:28:44PM +0200, Denis Kudriashov wrote: > > Hi Stef. > > > > It is really good idea. And it makes me think why we ask users for real > > icon Form and not just name? > > Because ThemeIcons may not be the only place from which you draw icons, and because programming with strings doesn't scale. > > In any case, assuming we can easily customize the icon retrieval (with the default being Smalltalk ui icons), then I have no problems with this. > > Btw, there was a push to use also `#smallFindIcon asIcon`, I am not sure if this is possible in Pharo 6. (this is nice and short for standard icons, but cannot be customized, which is sometimes problem). > > Pharo > > > > > We could say any component which shows icons should be created with > > concrete ThemeIcons ("Smalltalk ui icons" by default) to retrieve actual > > form by name. And users should always specify icon names instead of forms. > > > > What you think? > > > > > > > > > 2016-10-12 13:25 GMT+02:00 stepharo <stepharo(a)free.fr>: > > > > > Hi glamourers and other > > > > > > Hi > > > > > > I'm currently enhancing the API of Settings to propose to the users to > > > pass not an icon but an icon named so that all the clients are not force to > > > use. See below. > > > > > > Now it would be great if Glamour could do the same. > > > > > > Doru and Andrei? > > > > > > > > > menuOn: aBuilder > > > "Specify the menu used when writing text." > > > <contextMenu> > > > <RubLineNumberMenu> > > > (aBuilder item: #'Find...' translated) > > > keyText: 'f'; > > > selector: #find; > > > icon: (Smalltalk ui icons iconNamed: #smallFindIcon) > > > > > > ====> > > > > > > menuOn: aBuilder > > > "Specify the menu used when writing text." > > > <contextMenu> > > > <RubLineNumberMenu> > > > (aBuilder item: #'Find...' translated) > > > keyText: 'f'; > > > selector: #find; > > > iconNamed: #smallFindIcon > > > > > > > > > Stef > > > > > > > > > > > >

Oct. 12, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Peter Uhnak

On Wed, Oct 12, 2016 at 02:28:44PM +0200, Denis Kudriashov wrote: > Hi Stef. > > It is really good idea. And it makes me think why we ask users for real > icon Form and not just name? Because ThemeIcons may not be the only place from which you draw icons, and because programming with strings doesn't scale. In any case, assuming we can easily customize the icon retrieval (with the default being Smalltalk ui icons), then I have no problems with this. Btw, there was a push to use also `#smallFindIcon asIcon`, I am not sure if this is possible in Pharo 6. (this is nice and short for standard icons, but cannot be customized, which is sometimes problem). Pharo > > We could say any component which shows icons should be created with > concrete ThemeIcons ("Smalltalk ui icons" by default) to retrieve actual > form by name. And users should always specify icon names instead of forms. > > What you think? > > > 2016-10-12 13:25 GMT+02:00 stepharo <stepharo(a)free.fr>: > > > Hi glamourers and other > > > > Hi > > > > I'm currently enhancing the API of Settings to propose to the users to > > pass not an icon but an icon named so that all the clients are not force to > > use. See below. > > > > Now it would be great if Glamour could do the same. > > > > Doru and Andrei? > > > > > > menuOn: aBuilder > > "Specify the menu used when writing text." > > <contextMenu> > > <RubLineNumberMenu> > > (aBuilder item: #'Find...' translated) > > keyText: 'f'; > > selector: #find; > > icon: (Smalltalk ui icons iconNamed: #smallFindIcon) > > > > ====> > > > > menuOn: aBuilder > > "Specify the menu used when writing text." > > <contextMenu> > > <RubLineNumberMenu> > > (aBuilder item: #'Find...' translated) > > keyText: 'f'; > > selector: #find; > > iconNamed: #smallFindIcon > > > > > > Stef > > > > > > > >

Oct. 12, 2016

Re: [Pharo-dev] About icon: and iconNamed:

by Denis Kudriashov

Hi Stef. It is really good idea. And it makes me think why we ask users for real icon Form and not just name? We could say any component which shows icons should be created with concrete ThemeIcons ("Smalltalk ui icons" by default) to retrieve actual form by name. And users should always specify icon names instead of forms. What you think? 2016-10-12 13:25 GMT+02:00 stepharo <stepharo(a)free.fr>: > Hi glamourers and other > > Hi > > I'm currently enhancing the API of Settings to propose to the users to > pass not an icon but an icon named so that all the clients are not force to > use. See below. > > Now it would be great if Glamour could do the same. > > Doru and Andrei? > > > menuOn: aBuilder > "Specify the menu used when writing text." > <contextMenu> > <RubLineNumberMenu> > (aBuilder item: #'Find...' translated) > keyText: 'f'; > selector: #find; > icon: (Smalltalk ui icons iconNamed: #smallFindIcon) > > ====> > > menuOn: aBuilder > "Specify the menu used when writing text." > <contextMenu> > <RubLineNumberMenu> > (aBuilder item: #'Find...' translated) > keyText: 'f'; > selector: #find; > iconNamed: #smallFindIcon > > > Stef > > > >

Oct. 12, 2016

About icon: and iconNamed:

by stepharo

Hi glamourers and other Hi I'm currently enhancing the API of Settings to propose to the users to pass not an icon but an icon named so that all the clients are not force to use. See below. Now it would be great if Glamour could do the same. Doru and Andrei? menuOn: aBuilder "Specify the menu used when writing text." <contextMenu> <RubLineNumberMenu> (aBuilder item: #'Find...' translated) keyText: 'f'; selector: #find; icon: (Smalltalk ui icons iconNamed: #smallFindIcon) ====> menuOn: aBuilder "Specify the menu used when writing text." <contextMenu> <RubLineNumberMenu> (aBuilder item: #'Find...' translated) keyText: 'f'; selector: #find; iconNamed: #smallFindIcon Stef

Oct. 12, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60259 Home: https://github.com/pharo-project/pharo-core

Oct. 12, 2016

[pharo-project/pharo-core] 541e22: 60259

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 541e22ef70dc867a4dae568b9a7a05c8d6089fc6 https://github.com/pharo-project/pharo-core/commit/541e22ef70dc867a4dae568b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-10-12 (Wed, 12 Oct 2016) Changed paths: A ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/versions/version0105_.st M Glamour-FastTable.package/TGLMFastTable.class/instance/menu/menuColumn_row_.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/class/accessing/rowLeftMargin.st M OpalCompiler-Core.package/OpalEncoderForSistaV1.class/instance/extended bytecode generation/genPushFullClosure_numCopied_receiverOnStack_outerContextNeeded_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60258.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60259.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60258.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60259.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60259 19203 Debugging code left in Encoders https://pharo.fogbugz.com/f/cases/19203 19199 Enable / Disable options in context Menu in FastTable https://pharo.fogbugz.com/f/cases/19199 http://files.pharo.org/image/60/60259.zip

Oct. 12, 2016

Re: [Pharo-dev] Can Pharo VM be altered to act like GNUStep as well?

by Dimitris Chloupis

Indeed that pragma looks like a shared memory macro to me Actually one thing I found out is that DLLs and Shared Libraries are implemented via shared memory mapped files without giving access to shared memory. CodeDmitry I did get your message as you can see by the quote of my last reply. You are basically using Shared Memory IPC , its just an ungly Windows hack via a pragma and from the thread that Phil linked it looks like its also bug prone. This is also confirmed by Mircrosoft itself here -> https://msdn.microsoft.com/en-us/library/h90dkhs0(v=vs.90).aspx Summary: Use shared memory mapped files, far safer and far more cross platform On Wed, Oct 12, 2016 at 11:12 AM phil(a)highoctane.be <phil(a)highoctane.be> wrote: > #pragma data_seg("SHARED") > > looks like this is doing some serious IPC magic behing the scenes. > > Check this out for some critters: > https://social.msdn.microsoft.com/Forums/vstudio/en-US/bc93445e-cec3-456d-9… > > Phil > > On Wed, Oct 12, 2016 at 9:34 AM, CodeDmitry <dimamakhnin(a)gmail.com> wrote: > > Have you got my modified message? or have I been wasting my revisions all > along O.o? I'll repost. > > > O.o can you please elaborate? > > I wrote a DLL a while ago that successfully shared the global state it > exported between the callers that without any shared memory explicitly > being > created. > > I'll recreate a test case to make sure that I am not just lying. > > *Solution SharingDemo*: > *Project ShareMe*: > *ShareMe.cpp*: > #pragma data_seg("SHARED") > extern "C" { > __declspec(dllexport) > int sharedInteger = 0; > } > #pragma data_seg() > > #pragma comment(linker, "/section:SHARED,RWS") > > *Project Client1*: > *main.cpp*: > #include <Windows.h> > #include <stdio.h> > > int main(int argc, char **argv) > { > HMODULE module_handle = LoadLibrary("ShareMe.dll"); > int *shared_integer_handle = (int *)GetProcAddress(module_handle, > "sharedInteger"); > printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle); > > *shared_integer_handle = 1337; > > printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle); > > system("pause"); > return 0; > } > > *Project Client2*: > *main.cpp*: > #include <Windows.h> > #include <stdio.h> > > int main(int argc, char **argv) > { > HMODULE module_handle = LoadLibrary("ShareMe.dll"); > int *shared_integer_handle = (int *)GetProcAddress(module_handle, > "sharedInteger"); > printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle); > > *shared_integer_handle = 0; > > printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle); > > system("pause"); > return 0; > } > > now, debug client1, then debug client2. Client 2 should start with mutated > shared state(1337). > > > > > -- > View this message in context: > http://forum.world.st/Can-Pharo-VM-be-altered-to-act-like-GNUStep-as-well-t… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > >

Oct. 12, 2016

Re: [Pharo-dev] Can Pharo VM be altered to act like GNUStep as well?

by phil＠highoctane.be

#pragma data_seg("SHARED") looks like this is doing some serious IPC magic behing the scenes. Check this out for some critters: https://social.msdn.microsoft.com/Forums/vstudio/en-US/bc93445e-cec3-456d-9… Phil On Wed, Oct 12, 2016 at 9:34 AM, CodeDmitry <dimamakhnin(a)gmail.com> wrote: > Have you got my modified message? or have I been wasting my revisions all > along O.o? I'll repost. > > > O.o can you please elaborate? > > I wrote a DLL a while ago that successfully shared the global state it > exported between the callers that without any shared memory explicitly > being > created. > > I'll recreate a test case to make sure that I am not just lying. > > *Solution SharingDemo*: > *Project ShareMe*: > *ShareMe.cpp*: > #pragma data_seg("SHARED") > extern "C" { > __declspec(dllexport) > int sharedInteger = 0; > } > #pragma data_seg() > > #pragma comment(linker, "/section:SHARED,RWS") > > *Project Client1*: > *main.cpp*: > #include <Windows.h> > #include <stdio.h> > > int main(int argc, char **argv) > { > HMODULE module_handle = LoadLibrary("ShareMe.dll"); > int *shared_integer_handle = (int *)GetProcAddress(module_handle, > "sharedInteger"); > printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle); > > *shared_integer_handle = 1337; > > printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle); > > system("pause"); > return 0; > } > > *Project Client2*: > *main.cpp*: > #include <Windows.h> > #include <stdio.h> > > int main(int argc, char **argv) > { > HMODULE module_handle = LoadLibrary("ShareMe.dll"); > int *shared_integer_handle = (int *)GetProcAddress(module_handle, > "sharedInteger"); > printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle); > > *shared_integer_handle = 0; > > printf("*(shared_integer_handle) = %d.\n", *shared_integer_handle); > > system("pause"); > return 0; > } > > now, debug client1, then debug client2. Client 2 should start with mutated > shared state(1337). > > > > > -- > View this message in context: http://forum.world.st/Can- > Pharo-VM-be-altered-to-act-like-GNUStep-as-well-tp4918693p4918720.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Oct. 12, 2016