- Pharo-dev - lists.pharo.org

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

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

by CodeDmitry

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 Dimitris Chloupis

Here you go http://stackoverflow.com/questions/19373061/what-happens-to-global-and-stat… On Wed, 12 Oct 2016 at 02:33, CodeDmitry <dimamakhnin(a)gmail.com> wrote: > O.o can you please elaborate? > > I wrote a DLL a while ago that successfully shared the global state it > exported between the libraries that included it without any shared memory > explicitly being created. > > I'll recreate a test case to make sure that I am not just lying. > > > > -- > 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 CodeDmitry

O.o can you please elaborate? I wrote a DLL a while ago that successfully shared the global state it exported between the libraries that included it without any shared memory explicitly being created. I'll recreate a test case to make sure that I am not just lying. -- 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 Dimitris Chloupis

Shared libraries if you refer to DLLs it's actually a bad name, it's one of the rare occasions that Microsoft got the naming correct. It's actually a dynamically linked library, there is no sharing of execution or data and that applies for all OSes whether they call them shared libraries or not. Actually shared memory is one of the very few exception that an OS will share memory and even in that case you won't be given the data or code memory of another process . So each time an executable loads the DLL/Shared Library a new instance get linked dynamically with its own execution and data memory which only the executable that is linked to can access , however only one executable can do this. If that was not the case then there would be no reason to use Shared Memory and we all would be using DLLs.if you want share data , shared memory is your only option, other IPCs just copy memory around. On Wed, 12 Oct 2016 at 00:49, CodeDmitry <dimamakhnin(a)gmail.com> wrote: > Is the layering really that horrible as long as the library is already > shared > because it is shared between processes (being in shared libraries which are > relies on by many programs), and as long as as much of that overhead is > stripped at compile time? > > > > -- > 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 CodeDmitry

Is the layering really that horrible as long as the library is already shared because it is shared between processes (being in shared libraries which are relies on by many programs), and as long as as much of that overhead is stripped at compile time? -- 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. 11, 2016