Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- 1 participants
- 144633 messages
Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso
by Guillermo Polito
Hi,
yes this is cool :)
There is also a new smart student that will work on this infrastructure a
bit to make it "normal developer friendly", you know, hiding some
implementation details, making maybe a UI for the process and so on.
Now, about the questions:
- And how much smaller could the image get if the class builder was removed?
Well, as Pavel says, you can get for example 10K. You can get even less
if you tweak it manually. Around 10k is the minimal required by the VM to
run a full featured image (at least in cog 32 bits, I did not measure it in
Spur). Imagine that the VM requires at least:
* one process scheduler
* one process in that scheduler
* one context on that process
* one method on that context
Then, the VM requires some information to interact with the runtime,
e.g.,
* what is the selector used for doesNotUnderstand: (yes, we can change
it!)
* what are the first 256 character objects in the Character flyweight
* what is the class of SmallInteger immediate instances
* some special/optimized selectors
My automatic process generated a somewhat 10k of objects required for
this VM/image interaction.
Of course this list changes a bit with Spur, and could be reduced (for
example, if you don't use characters, you wouldn't need the character
flyweight and so on...)
- Is it future approach for bootstrap? (with respect to the 10k image)
Well, if you read my thesis, what I'm doing there is to lazily pick what
classes and methods will go inside an image. While this is nice to
experiment, I do not think It's a good approach for bootstrapping:
* you need to exercise/execute all possible cases your image needs to
support
* and that means you need to know all those cases in advance
* and that you have to be careful with side effects
Otherwise, code not executed is not taken in the resulting image.
Also take the fact that changing a little line of code may result in
bootstrapping an image a couple of times bigger because of a wrong
dependency.
All these points make this approach less reproducible and a bit more
complicated. I prefer an explicit list of packages to bootstrap, that we
can control and really test the output :)
Also, as Igor says, we could be able to generate an image without a class
builder, as we are able to generate an image without a compiler. But we do
not want to. Because that is an image that we cannot almost interact with.
We cannot load code inside. So the more interesting question is where is
the balance between space and functionality.
BTW Pavel, this approach may need to be updated but I think we could make
it run on top of the simulator also ;).
- How faster or slower bootstrap process with it?
They are not really comparable. They do not use the same infrastructure,
nor the same process, and they do not generate the same results.
The 10k image is of course generated in a matter of seconds, but a 600k
image containing the seaside counter may take half an hour.
In our current approach, the speed of bootstrap is directly related to
the number of classes and methods inside the result. There are two ways to
speed up the process:
- by speeding up the ast interpreter (or replacing it by a compiled
version of it)
- and by cleaning the kernel
Guille
On Fri, Feb 24, 2017 at 9:15 PM, Igor Stasenko <siguctua(a)gmail.com> wrote:
>
>
> On 24 February 2017 at 21:01, Pavel Krivanek <pavel.krivanek(a)gmail.com>
> wrote:
>
>>
>> 2017-02-24 17:17 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>:
>>
>>>
>>> 2017-02-24 16:36 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>:
>>>
>>>> The "guest" object memory runs in a special virtual machine simulator
>>>> during the bootstrapping. That simulator uses AST Interpreter to execute
>>>> the code inside the guest environment before it is installed for real. It
>>>> uses own special kind of proxies and tricks to do it. The current bootstrap
>>>> cannot run without class builder in the guest environment, but...
>>>>
>>>>
>>>>> And how much smaller could the image get if the class builder was
>>>>> removed.
>>>>>
>>>>
>>>> ...Guille in his thesis tried different approaches and he was able to
>>>> produce extremely small images (~10 KiB) that did for example only a sum
>>>> of two numbers.
>>>>
>>>
>>> Is it future approach for bootstrap?
>>> How faster or slower bootstrap process with it?
>>>
>>
>> That's more question for Guille, but I do not think we will adopt this
>> approach of bootstrapping in near future because it needs to be updated for
>> the Spur format and it needs a special VM modifications. And the question
>> is how much is it really needed because if you want to do something with
>> the image, you will anyway need most of methods needed for the class
>> builder like basic strings and collections support.
>>
>>
> I think, you can shrink image even more, by running something after
> booting it to remove ClassBuilder & co, if you don't need to create classes
> etc.
>
> --
> Best regards,
> Igor Stasenko.
>
Feb. 28, 2017
Re: [Pharo-dev] How to listen for windows messages?
by Dimitris Chloupis
> How can I set up a windows message hook in Pharo?
> Please keep in mind I'm very new to programming, but I work from home and
> have lots of time to learn :-)
>
First of all Torsten gave you an excellent answer. If read it once, go
reread it 10 times and bookmark it. Second of all I cannot answer precisely
what code you will need because I have not done this before.
I did have a recent experience with UFFI. Apart from some of the basics of
UFFI that you need to be aware of , everything else is pretty
straightforward.
I did work with shared memory mapped files which is an extremely low level
functionality of an OS, so low level that is included in the OS kernel and
forms the basic of OS memory management. I expected to be insanely hard and
I was suprised how simple it was. It started as a joke (how to make Pharo
controll C++ applications) it turned out into a serious Pharo library
(CPP).
The main reason for this is the fact that UFFI keeps the C syntax almost
intact when it comes to function signatures. But the big catch here is that
you need to be familiar with C and the libraries you are going to use. It
will be super easy to use them from Pharo but the task itself may not.
Pharo maybe be a higher level language but C is not. C is not low level but
still you need to know how to do manual memory management and also OS APIs
tend to be quite technical too.
The general idea is that Pharo will follow the C approach to the letter
even when it comes to manual memory management. So if you do not know C ,
drop anything you do and go learn it NOW.
My advice is to NOT i repeat DO NOT do this in Pharo.
First do this in C.
Why ?
First of all you will find tons of example code online, so all you have to
do is copy paste and modify accordingly.
So getting the code to work is suprisingly easy but understanding the code
and why when you made changes started crashing for no apparent reason is a
lot more difficult.
Second of all Pharo IDE may be awesome but is made to be used with Pharo
not with C libraries. A C debugger and generally a C ide , in case of
windows Visual Studio is free and very efficient will help you deal with
bugs a lot easier.
When a bug happens in Pharo , the IDE practically takes you by the hand and
helps you find it and correct it.
When a bug happens in C code , even C code run from inside Pharo via UFFI
it will crash your C executable or Pharo itself and no error will be
displayed apart from extremely limited information.
However this comparison is unfair because Pharo comes with an IDE , C
usually does not.
But C with Visual Studio or other IDEs will help you get very close to
Pharo experience. Obviously not the same , but quite close none the less.
Generally my approach was to start with prints , printing values and
information to track exactly what went wrong with my C code . Then when
prints became too many I used Visual Studio debugger breakpoints, that stop
execution so you can examine what code is actually executed and fails and
watchpoints which basically keep track of data inside variables so you can
find bugs that are more tricky to find than executing the wrong code.
Also find a C forum and ask question. You wont get much help here because
even though UFFI is very important the vast majority of Pharo coders prefer
to stay away from C coding because C coding is not Pharo coding.
If you figure out how to do this in C it will take you literally minutes to
port it to Pharo , its pretty much the exactly same process and exactly
same code. Well almost.
The process is the same for any C library and C code called from Pharo, the
rest is just techncial documentation which you will find a ton online.
Thats one of the advantages of using a popular language like C.
So go and do this in C and make sure it works in C then try to port it to
Pharo. If Pharo gives you any problems you can always copy paste your code
here, or preferably using an online code snippet service like pastebin or
gist and we will guide you through how to fix your errors since the process
is the same for all C code.
Feb. 28, 2017
Re: [Pharo-dev] How to listen for windows messages?
by phil@highoctane.be
Hi,
Pharo is itself a Windows application (under Windows of course).
So Window event loop is picking up the events and transforming them into
Pharo events.
You can check this in https://github.com/pharo-project/pharo-vm
in opensmalltalk-vm\platforms\win32\vm\sqWin32Window.c
https://github.com/pharo-project/pharo-vm/blob/master/opensmalltalk-vm/plat…
Like L235...
LRESULT CALLBACK MainWndProcW(HWND hwnd,
UINT message,
WPARAM wParam,
LPARAM lParam)
You'll see that we stick a lot of stuff into evt->... in various ways.
There is a default fallback at the end.
default:
/* Unprocessed messages may be processed outside the current
module. If firstMessageHook is non-NULL and returns a non
zero value, the message has been successfully processed */
if(firstMessageHook)
if((*firstMessageHook)(hwnd, message, wParam, lParam))
return 1;
return DefWindowProcW(hwnd,message,wParam,lParam);
{
So, if firstMessageHook exists, one can do whatever.
Now, a Windows manager may need other stuff and so on.
What you are looking at is how to hook this VM side with more of the
general Windows system.
These hooks are globals, so should be accessible.
/****************************************************************************/
/* Message Processing */
/****************************************************************************/
/* The last dispatched event. It is used for the event processing
mechanism. */
MSG *lastMessage = NULL;
/* The entry to the message hooks called from the window procedure.
If another module requires to process messages by itself, it should
put its message procedure in this place. */
messageHook firstMessageHook = 0;
/* The entry to a pre-message hook. Can be used to intercept any messages
to the squeak main window. Useful for modules that wish to be notified
about certain messages before they are processed. */
messageHook preMessageHook = 0;
Never played with these but any Windows integration is of interest to me.
So, go ahead. Nothing would resist focused work.
Be aware that there is another VM underway with a cleanup of all of this
but this is not released yet.
Keep us posted.
Phil
On Tue, Feb 28, 2017 at 9:33 AM, Torsten Bergmann <astares(a)gmx.de> wrote:
>
> Hi,
>
> I guess what you want to achieve will not be an easy task for you if you
are new to programming.
> But it is always good to have a goal and if you have time to learn I'm
pretty sure you will master
> it.
>
> Even when OS-Windows inspire you for automizing tasks in other Windows
processes (like autoit) you
> should not start with my OS-Windows project directly as contributing to
it requires knowledge
> on your side on Smalltalk as well as Win32 C programming.
>
> First start with learning Smalltalk and Pharo
> - http://files.pharo.org/books/
> - http://pharo.pharocloud.com/pharobooks
> - http://stephane.ducasse.free.fr/FreeBooks.html
>
> After having an idea about Smalltalk and Pharo you should try to learn
UFFI which
> is Pharos unified foreign function interface and ability to call C DLL's.
>
>
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre…
>
> Sideways start learning about the Win32 API and C as this helps to better
understand
> how things are done on the Windows side. There are many, many tutorials
out there.
> Try to call or wrap some simple DLL functions on you own first.
>
> There is a nice and tiny C compiler if you want to try out some C samples
> http://www.pellesc.de/index.php?page=download&lang=en
>
> With this initial knowledge you can try to understand why and how
OS-Windows was done.
> I wrote many tests - just add a breakpoint and run them to debug through
the code to understand.
> Google for the API descriptions of the Win32 functions that are called to
get an understanding
> how Pharo and C get connected.
>
> Also check how you work with callbacks in UFFI (as this would be required
for a hook).
>
> If you are then still interested in interception windows messages you
should start reading here
>
https://msdn.microsoft.com/en-us/library/windows/desktop/ms632589(v=vs.85).…
>
> Primarily one has to wrap SetWindowsHookEx API function and friends and
wrap a good API
> for them in Pharo.
>
> Hope that helps to get started.
>
> Regards
> Torsten
>
> > Gesendet: Dienstag, 28. Februar 2017 um 06:04 Uhr
> > Von: lw1990 <lukewallace1990(a)gmail.com>
> > An: pharo-dev(a)lists.pharo.org
> > Betreff: [Pharo-dev] How to listen for windows messages?
> >
> > In the OS-Windows package, there exists the ability to use the windows
api in
> > Pharo.
> > This is very powerful, and I intend to add more of the windows api into
it
> > (it's only partially implemented).
> >
> > This appears to all have been done with DllCalls (FFI calls) so far.
> >
> > A big part of interacting with windows is listening to/intercepting and
> > responding to windows messages.
> > For example, every time a user presses a key on the keyboard, a windows
> > message will happen in the background for that key. If Pharo was aware
of
> > these messages, then Pharo could do things in response to hotkeys
pressed on
> > Windows (outside of a pharo window).
> >
> > It would also make reacting to events potentially nicer. Like making a
> > windows-desktop-manager in Pharo that can tell when a new window is
created
> > by windows (maybe they opened notepad). It would certainly be better
than an
> > infinite loop or timer of 'get active window and compare to last active
> > window and see if it changed'. Instead it would be 'when receive the
> > WM_MESSAGE for new window created, notify Pharo so it can react'.
> >
> > How can I set up a windows message hook in Pharo?
> > Please keep in mind I'm very new to programming, but I work from home
and
> > have lots of time to learn :-)
> >
> >
> >
> > --
> > View this message in context:
http://forum.world.st/How-to-listen-for-windows-messages-tp4936285.html
> > Sent from the Pharo Smalltalk Developers mailing list archive at
Nabble.com.
> >
> >
>
Feb. 28, 2017
[pharo-project/pharo-core] 17e26d: 60416
by GitHub
Branch: refs/heads/6.0
Home: https://github.com/pharo-project/pharo-core
Commit: 17e26d8fd2926a817bf37b64aaab0eb9ec522fe7
https://github.com/pharo-project/pharo-core/commit/17e26d8fd2926a817bf37b64…
Author: Jenkins Build Server <board(a)pharo-project.org>
Date: 2017-02-28 (Tue, 28 Feb 2017)
Changed paths:
M BaselineOfIDE.package/BaselineOfIDE.class/instance/actions/additionalInitialization.st
M BaselineOfIDE.package/BaselineOfIDE.class/instance/baseline/baseline_.st
M BaselineOfIDE.package/BaselineOfIDE.class/instance/baseline/groups_.st
M PharoBootstrap-Initialization.package/PharoBootstrapInitialization.class/class/public api/initializeCommandLineHandlerAndErrorHandling.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60415.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60416.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60415.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60416.st
M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
Log Message:
-----------
60416
19732 Reenable Catalog loading in Spotter and fix confusing/hidden setting for it
https://pharo.fogbugz.com/f/cases/19732
19769 BaselineOfIDE needs update
https://pharo.fogbugz.com/f/cases/19769
19771 remove debugging "Alive" report during the bootstrap initialization
https://pharo.fogbugz.com/f/cases/19771
http://files.pharo.org/image/60/60416.zip
Feb. 28, 2017
[pharo-project/pharo-core]
by GitHub
Branch: refs/tags/60416
Home: https://github.com/pharo-project/pharo-core
Feb. 28, 2017
[pharo-project/pharo-core]
by GitHub
Branch: refs/tags/60415
Home: https://github.com/pharo-project/pharo-core
Feb. 28, 2017
[pharo-project/pharo-core] cf01ef: 60415
by GitHub
Branch: refs/heads/6.0
Home: https://github.com/pharo-project/pharo-core
Commit: cf01ef14fd52d7b674eba24651c1e62ab1f388a3
https://github.com/pharo-project/pharo-core/commit/cf01ef14fd52d7b674eba246…
Author: Jenkins Build Server <board(a)pharo-project.org>
Date: 2017-02-28 (Tue, 28 Feb 2017)
Changed paths:
A Collections-Abstract.package/Collection.class/class/instance creation/empty.st
M Collections-Abstract.package/Collection.class/class/instance creation/with_.st
A Collections-Abstract.package/HashedCollection.class/class/instance creation/empty.st
M Collections-Abstract.package/HashedCollection.class/class/instance creation/new.st
A Collections-Tests.package/HashTableSizesTest.class/README.md
A Collections-Tests.package/HashTableSizesTest.class/definition.st
A Collections-Tests.package/HashTableSizesTest.class/instance/tests/testAtLeast.st
M Collections-Unordered.package/HashTableSizes.class/README.md
A Collections-Unordered.package/HashTableSizes.class/class/class initialization/initialize.st
R Collections-Unordered.package/HashTableSizes.class/class/initialize-release/initialize.st
A Collections-Unordered.package/HashTableSizes.class/class/private/basicAtLeast_.st
A Collections-Unordered.package/HashTableSizes.class/class/private/maxSmallSize.st
M Collections-Unordered.package/HashTableSizes.class/class/private/sizes.st
A Collections-Unordered.package/HashTableSizes.class/class/private/smallSizesLookupTable.st
M Collections-Unordered.package/HashTableSizes.class/class/public/atLeast_.st
R Collections-Unordered.package/Set.class/class/instance creation/new.st
M Collections-Unordered.package/Set.class/class/instance creation/newFrom_.st
M Debugger-Tests.package/DebuggerModelTest.class/instance/tests/testStepInto.st
M Morphic-Widgets-Tabs.package/TabManagerMorph.class/instance/private-actions/tabRefreshed_.st
M Morphic-Widgets-Tabs.package/TabManagerMorph.class/instance/private-contents/addLastTabContents_among_delta_.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60414.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60415.st
R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60414.st
A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60415.st
M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st
M System-Identification.package/GlobalIdentifierPersistence.class/instance/configuration/defaultPreferences.st
Log Message:
-----------
60415
19763 TabManagerMorph do not respect multipleContents mode when tabs are built in background
https://pharo.fogbugz.com/f/cases/19763
19762 Optimize small Dictionary and Set creation
https://pharo.fogbugz.com/f/cases/19762
19459 add #empty instance creation method
https://pharo.fogbugz.com/f/cases/19459
19502 Starting Pharo creates a .ston file in appdata directory
https://pharo.fogbugz.com/f/cases/19502
http://files.pharo.org/image/60/60415.zip
Feb. 28, 2017
Re: [Pharo-dev] How to listen for windows messages?
by Torsten Bergmann
Hi,
I guess what you want to achieve will not be an easy task for you if you are new to programming.
But it is always good to have a goal and if you have time to learn I'm pretty sure you will master
it.
Even when OS-Windows inspire you for automizing tasks in other Windows processes (like autoit) you
should not start with my OS-Windows project directly as contributing to it requires knowledge
on your side on Smalltalk as well as Win32 C programming.
First start with learning Smalltalk and Pharo
- http://files.pharo.org/books/
- http://pharo.pharocloud.com/pharobooks
- http://stephane.ducasse.free.fr/FreeBooks.html
After having an idea about Smalltalk and Pharo you should try to learn UFFI which
is Pharos unified foreign function interface and ability to call C DLL's.
https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre…
Sideways start learning about the Win32 API and C as this helps to better understand
how things are done on the Windows side. There are many, many tutorials out there.
Try to call or wrap some simple DLL functions on you own first.
There is a nice and tiny C compiler if you want to try out some C samples
http://www.pellesc.de/index.php?page=download&lang=en
With this initial knowledge you can try to understand why and how OS-Windows was done.
I wrote many tests - just add a breakpoint and run them to debug through the code to understand.
Google for the API descriptions of the Win32 functions that are called to get an understanding
how Pharo and C get connected.
Also check how you work with callbacks in UFFI (as this would be required for a hook).
If you are then still interested in interception windows messages you should start reading here
https://msdn.microsoft.com/en-us/library/windows/desktop/ms632589(v=vs.85).…
Primarily one has to wrap SetWindowsHookEx API function and friends and wrap a good API
for them in Pharo.
Hope that helps to get started.
Regards
Torsten
> Gesendet: Dienstag, 28. Februar 2017 um 06:04 Uhr
> Von: lw1990 <lukewallace1990(a)gmail.com>
> An: pharo-dev(a)lists.pharo.org
> Betreff: [Pharo-dev] How to listen for windows messages?
>
> In the OS-Windows package, there exists the ability to use the windows api in
> Pharo.
> This is very powerful, and I intend to add more of the windows api into it
> (it's only partially implemented).
>
> This appears to all have been done with DllCalls (FFI calls) so far.
>
> A big part of interacting with windows is listening to/intercepting and
> responding to windows messages.
> For example, every time a user presses a key on the keyboard, a windows
> message will happen in the background for that key. If Pharo was aware of
> these messages, then Pharo could do things in response to hotkeys pressed on
> Windows (outside of a pharo window).
>
> It would also make reacting to events potentially nicer. Like making a
> windows-desktop-manager in Pharo that can tell when a new window is created
> by windows (maybe they opened notepad). It would certainly be better than an
> infinite loop or timer of 'get active window and compare to last active
> window and see if it changed'. Instead it would be 'when receive the
> WM_MESSAGE for new window created, notify Pharo so it can react'.
>
> How can I set up a windows message hook in Pharo?
> Please keep in mind I'm very new to programming, but I work from home and
> have lots of time to learn :-)
>
>
>
> --
> View this message in context: http://forum.world.st/How-to-listen-for-windows-messages-tp4936285.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>
>
Feb. 28, 2017
How to listen for windows messages?
by lw1990
In the OS-Windows package, there exists the ability to use the windows api in
Pharo.
This is very powerful, and I intend to add more of the windows api into it
(it's only partially implemented).
This appears to all have been done with DllCalls (FFI calls) so far.
A big part of interacting with windows is listening to/intercepting and
responding to windows messages.
For example, every time a user presses a key on the keyboard, a windows
message will happen in the background for that key. If Pharo was aware of
these messages, then Pharo could do things in response to hotkeys pressed on
Windows (outside of a pharo window).
It would also make reacting to events potentially nicer. Like making a
windows-desktop-manager in Pharo that can tell when a new window is created
by windows (maybe they opened notepad). It would certainly be better than an
infinite loop or timer of 'get active window and compare to last active
window and see if it changed'. Instead it would be 'when receive the
WM_MESSAGE for new window created, notify Pharo so it can react'.
How can I set up a windows message hook in Pharo?
Please keep in mind I'm very new to programming, but I work from home and
have lots of time to learn :-)
--
View this message in context: http://forum.world.st/How-to-listen-for-windows-messages-tp4936285.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Feb. 28, 2017
Re: [Pharo-dev] NetNameResolver graph of primitive senders
by Ben Coman
The over-arching goal is to udnerstand and maybe fix this timeout issue.
I first jumped straight to reviewing sqUnixSocket.c but at 2250 lines it
wasn't clear where to start.
Then I noticed the following primitives were not called from the Image...
primGetAddressInfoFamily
primGetAddressInfoNext
primGetNameInfoServiceSize
primGetAddressInfoSize
primGetAddressInfoHost:service:flags:family:type:protocol:
primGetNameInfoHostResult:
primGetNameInfoServiceResult:
primGetAddressInfoResult:
primGetAddressInfoType
primGetNameInfoHostSize
primGetAddressInfoProtocol
and just wanted to get a better feel for how things fit together.
For example...
primNameResolverError is called by resolverError but this has no senders
in the Image.
Now btw, was it Linux images that were locking up? And/or other platforms?
cheers -ben
On Tue, Feb 28, 2017 at 3:18 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote:
> Ben,
>
> Nice work !
>
> So the conclusion is that only #addressForName:[timeout:] is used a lot
> and its counterpart #nameForAddress:[timeout:] just a little bit. Right ?
>
> What was your goal in doing this analysis ?
>
> Sven
>
> > On 27 Feb 2017, at 15:40, Ben Coman <btc(a)openinworld.com> wrote:
> >
> > Following up discussion on the Catalog sometimes delaying Spotter in
> locations with poor network
> > http://forum.world.st/Catalog-loading-in-Spotter-td4934969.html#a4935842
> >
> > Just sharing a poke I had at understanding the name resolution call
> chain down to the primitives.
> > Attached is a Roassal/Artefact generated PDF based on "methods" and
> "links" from this...
> >
> > methods := NetNameResolver class methods select: [:m | m selector
> beginsWith: 'prim']. "start with primitives"
> > methods := methods asSet.
> > prevMethods := #() asSet.
> > links := Set new.
> > 3 timesRepeat: [
> > |newMethods todo|
> > newMethods := methods difference: prevMethods.
> > prevMethods := methods copy.
> > todo := newMethods collect: [:m|
> > |senders|
> > ((((m methodClass inheritsFrom: TestAsserter)
> > or: [m selector = #new])
> > or: [m methodClass printString beginsWith:
> 'SmaCC'])
> > or: [m selector printString beginsWith: '#init'])
> > ifTrue: [m -> #()]
> > ifFalse: [m -> (m senders collect: [:rgmd| rgmd
> compiledMethod])].
> > ].
> > todo := todo select: [:sendersOf| sendersOf value size > 0].
> "remove fluff"
> > todo := todo sorted: [:sendersOf1 :sendersOf2| sendersOf1 value
> size > sendersOf2 value size]. "helps debugging"
> > todo do: [:sendersOf|
> > sendersOf value do: [:sender|
> > methods add: sender.
> > links add: (sender->sendersOf key).
> > ]
> > ].
> > ].
> > methods copy do: [:m| links detect: [:l| (m = l key) or: [ m = l value]
> ] ifNone: [ methods remove: m]]. "remove fluff"
> >
> >
> >
> > After loading Roassal from the Catalog into 60411
> > I started with Mondrian to graph like this...
> >
> > b := RTMondrian new.
> > b shape box.
> > b nodes: methods forEach: [:each|
> > b shape
> > withText: [:m| m methodClass printString, String
> cr, m selector printString];
> > withTextColor: Color black.
> > b nodes: { each }.
> > b layout
> > ].
> > b shape arrowedLine withShorterDistanceAttachPoint.
> > links do: [:l| b edges connectFrom: l value to: l key].
> > b layout horizontalDominanceTree horizontalGap: 100.
> > b build.
> > b view inspect
> >
> > But I wanted to fine tune the layout by moving around a few subtrees
> > and couldn't work out how to add RTDraggableChildren to the Mondrian
> edges.
> >
> > So I tried Roassal direct like this...
> > v := RTView new.
> > v @ RTDraggableView.
> > labelTemplate := (RTLabel new text: [:m | m methodClass printString,
> String cr, m selector printString]).
> >
> > els := labelTemplate elementsOn: methods. "also see alternative
> below"
> > v addAll: els.
> > eb := RTEdgeBuilder new
> > view: v;
> > elements: els.
> >
> > links do: [:l| eb connectFrom: l value to: l key].
> > RTHorizontalDominanceTreeLayout on: els.
> > els @ RTDraggableChildren.
> > v inspect.
> >
> > But couldn't work out how to put a border around the RTLabel, nor change
> its background colour.
> > I saw RTShape>>#fillColor: and #fillColorElement: but couldn't determine
> how to make use of them.
> >
> > The best I could come up with is the following alternative that replaces
> > the code in the middle that assigns "els" and "eb" with...
> > els := RTBox elementsOn: methods.
> > v addAll: els.
> > RTNest new
> > for: els
> > add: [ :group :method |
> > group
> > addAll: (labelTemplate elementsOn:
> {method})].
> > eb := RTEdgeBuilder new
> > view: v;
> > elements: els.
> >
> > cheers -ben
> > <NetNameResolver-3level-primitive-senders.pdf>
>
>
>
Feb. 28, 2017