November 2013 - Pharo-users

CogVM arguments in Win32

by Torsten Bergmann

Hi Bernat, >how do I translate this into NB code Either invite Igor (author of NB) for lunch or try this: Its a C-structure, you convert it by wrapping this in a sublcass of "NBExternalStructure". See the examples already in a Pharo 3.0 image. Basically you need: - define a subclass NBExternalStructure subclass: #WinNotifyIconData ... - define the correct fields in a class side #fieldsDesc method according to the native data types used in the structure - call "WinNotifyIconData rebuildFieldAccessors" - setup the types in a shared pool that you can include later: - define the pool: SharedPool subclass: #WinTryIconConstants ... - in a class initialize method you can setup the type initialize NOTIFYICONDATA := #WinNotifyIconData. PNOTIFYICONDATA:= 'NOTIFYICONDATA *'. - by including the pool you can use "NOTIFYICONDATA" or "PNOTIFYICONDATA" in any native boost call. If you are in Pharo 3.0 load "OS-Windows" package from the config browser. Check the subclasses of NBExternalStructure there. I wrapped many other windows structures already so you can get an idea about it. For instance have a look at WinConsoleConstants>>initTypeConstants, there you will find the CONSOLE_CURSOR_INFO, CONSOLE_SCREEN_BUFFER_INFO structs wrapped in WinConsoleCursor, WinConsoleScreenBuffer classes. Compare them with the MSDN struct description. >Could the Windows API be any more convoluted and dev-unfriendly in any >possible sense? This question should go to M$ not Pharo-user ;) Bye T. BTW: I'm not sure "PNOTIFYICONDATA" alone will solve your problem if I remember correctly from my Smalltalk/MT and C/C++ times also playing with tray icons. I guess you need a callback that gets called when the icon is clicked or the tray icon menu is choosen (see uCallbackMessage member in the struct). You also need a handle to an icon - either the icon from the EXEs resource section or by loading one from a bitmap. That means wrapping the icon or bitmap apis too...

Nov. 13, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by Richard Wettel

Hi What Doru wrote pretty much sums it up. CodeCity under VW was based on JUN, which provided a programmer-friendly API built on top of OpenGL. Since there is no such thing under Pharo, when I later started to work on CodeCity under Pharo, I needed to learn about how to program directly to OpenGL. And the only example I had for that was SourceCity. In the meantime I manage to get a grip on my basic needs and was ready to move forward to implementing CodeCity. Now that does not work anymore in Pharo 3.0 so I am stuck. I could continue to program under Pharo 2.0, but what's the point? I have already looked at Roassal 3d, but it was not easy to separate the API from the code. And it is something completely different than what I have been using (and SourceCity, too), because Roassal 3d is using the modern OpenGL methodology (with FBOs and stuff). So, I would really appreciate if that API would find its way from Roassal to NBOpenGL and I could use it for CodeCity. Unfortunately I am able to help a lot with that, because I know very little about this and I also don't have enough time (I am doing CodeCity in my spare time). But, if you have concrete things that I can do, I'd be happy to help. Cheers Ricky On Wed, Nov 13, 2013 at 9:44 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I guess that what Ricky is asking is what changed between NBOpenGL 2.0 and > 3.0 such that this does not work anymore on Windows. The fact that he > mentioned 64 bits is not relevant for this discussion :). > > I also guess he wants to put some effort into understanding this as well > but he needs a bit of guidance. Right Ricky? > > Cheers, > Doru > > > > On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Richard >> >> you should have a look at ROASSAL 3d because ronie improved the shadder >> part (no more assembler) >> and his code should be split in two and one part should go to NBOpenGL. >> Now he is experiencing some problem with NBOpenGL on windows as you. >> >> NativeBoost does not work on 64 bits. Yet but igor is really busy >> finishing the texteditor (and I can tell you that >> he does not have fun there). >> >> So it is important that you help because we are FULL >> and sorry about that but really FULL. >> >> Ronie will visit us in January and share an office with igor. >> >> Stef >> >> >> > Hi >> > >> > CodeCity, the project I am working on is based on NBOpenGL. >> > I'd like to start working on it using Pharo 3, but it seems that >> NBOpenGL does not work yet with Pharo 3.0. >> > >> > I downloaded from jenkins the latest image with Pharo 3 and tried to >> execute the following code on Windows 7, 64 bits: >> > >> > GLTTRenderingDemo new openInWorld. >> > >> > but I get a 'No suitable implementation found for initializing OpenGL >> context for your platform'. >> > It seems that NBGLContextDriver does not have a subclass for Windows >> 64bits. Did I omit something? >> > >> > Cheers >> > Ricky >> > >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Nov. 13, 2013

Re: [Pharo-users] CogVM arguments in Win32

by Bernat Romagosa

Hi list, I made some progress but I'm still a bit lost here. I managed to get Pharo to be headless in Win32, by hiding the window via NB as Igor suggested, plus suspending the UI process (UIManager default uiProcess suspend), which was the cause for the window to show up again after a fraction of a second, because of the refresh interval. However, now I can only close Pharo by killing the process manually, which is not very nice for the end user. So I figured I'd try to add an icon to the system tray with a single context menu entry for closing Pharo. This is what I'm doing, taken from MSDN<http://msdn.microsoft.com/en-us/library/windows/desktop/bb762159(v=vs.85).a…> : NBWin32Shell >> shellNotifyIcon: lpdata dwMessage: dwMessage <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self nbCall: #(bool Shell_NotifyIcon( DWORD dwMessage, PNOTIFYICONDATA lpdata )) module: #shell32 dwMessage is just a 0 (flag to create a tray icon), but lpdata needs to be a pointer to a struct of this form<http://msdn.microsoft.com/en-us/library/windows/desktop/bb773352(v=vs.85).a…> : typedef struct _NOTIFYICONDATA { DWORD cbSize; HWND hWnd; UINT uID; UINT uFlags; UINT uCallbackMessage; HICON hIcon; TCHAR szTip[64]; DWORD dwState; DWORD dwStateMask; TCHAR szInfo[256]; union { UINT uTimeout; UINT uVersion; }; TCHAR szInfoTitle[64]; DWORD dwInfoFlags; GUID guidItem; HICON hBalloonIcon; } NOTIFYICONDATA, *PNOTIFYICONDATA; So, my question is: how do I translate this into NB code? How does one define a struct and then pass its pointer to a function in NativeBoost? Thanks a lot for your help, I'm getting closer :) Bernat. p.s. Could the Windows API be any more convoluted and dev-unfriendly in any possible sense? 2013/11/4 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > Hi! > > Thanks Igor, that kinda worked! Pharo hides, but comes back after half a > second or so. I'll keep digging, thanks! :) > > > 2013/11/1 phil(a)highoctane.be <phil(a)highoctane.be> > > Well, this should rather be: >> >> handle :=NativeBoostWin32 squeakWindowHandle. >> window := NBWin32Window new value: handle; yourself. >> window hide. >> >> or >> >> window setWindowText: 'im a main window blablabla'. >> >> Phil >> >> >> On Thu, Oct 31, 2013 at 10:03 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >> >>> You can try something like this: >>> >>> | handle window | >>> >>> handle := NativeBoost forCurrentPlatform squeakWindowHandle. >>> window := NBWin32Window new value: handle; yourself. >>> window hide. >>> >>> or >>> >>> window setWindowText: 'im a main window blablabla'. >>> >>> :) >>> >>> i didn't tested it since its been implemented, but i think it should >>> work. >>> >>> >>> >>> On 30 October 2013 11:20, Bernat Romagosa < >>> tibabenfortlapalanca(a)gmail.com> wrote: >>> >>>> In this direction, I'm trying to call a function in the shell32.dll lib >>>> that apparently should let you minimize an app to the system tray, but I'm >>>> not having much luck... I guess I don't really understand what am I exactly >>>> doing. >>>> >>>> This is what I found in the MSDN<http://msdn.microsoft.com/en-us/library/bb762159%28VS.85%29.aspx> >>>> : >>>> >>>> BOOL Shell_NotifyIcon( >>>> _In_ DWORD dwMessage, >>>> _In_ PNOTIFYICONDATA lpdata >>>> ); >>>> >>>> >>>> So, I tried to translate this into Pharo as: >>>> >>>> MyClass >> minimizeToTray: dwMessage data: lpData >>>> >>>> <apicall: bool 'Shell_NotifyIcon' (dword PNOTIFYICONDATA) module: >>>> 'shell32.dll'> >>>> >>>> >>>> But it won't let me save the method, reporting it's expecting an >>>> argument before PNOTIFYICONDATA. >>>> >>>> I realize PNOTIFYICONDATA is not a primitive type, but I just don't >>>> know how to handle it... :( >>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > -- > Bernat Romagosa. > -- Bernat Romagosa.

Nov. 13, 2013

Re: [Pharo-users] PetitParser and external streams

by Norbert Hartl

Am 12.11.2013 um 23:02 schrieb Sean P. DeNigris <sean(a)clipperadams.com>: > Federico.Balaguer wrote >> Hello, >> >> I am developing a parser with PetitParser and one of the options I would >> like to try is to get my parser to read from an external stream (file) and >> produce the output to another external stream (another file) >> >> Is this possible? I found that Stream>>asPetitParser do this: >> asPetitStream >> ^ self contents asPetitStream >> >> Thanks! Federico > Reading from a stream is the normal way to use petit parser. On the output side it isnât that easy. The parser builds a hierarchical structure with a lot of backtracking so writing sequentially to a stream needs eventually to be postponed until everything has been read. Producing the output immediately often has the drawback that it is hard to alter the stream in between. So the usual case will be that you make an object representation of your input format. Then you have a hierarchical object structure that you can write on an output stream. You could use the #printOn: method on all your model objects. Your task would then be accomplished by doing (MyParser parse: inputStream) printOn: outputStream hope this helps, Norbert

Nov. 13, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by Tudor Girba

Hi, I guess that what Ricky is asking is what changed between NBOpenGL 2.0 and 3.0 such that this does not work anymore on Windows. The fact that he mentioned 64 bits is not relevant for this discussion :). I also guess he wants to put some effort into understanding this as well but he needs a bit of guidance. Right Ricky? Cheers, Doru On Tue, Nov 12, 2013 at 2:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Richard > > you should have a look at ROASSAL 3d because ronie improved the shadder > part (no more assembler) > and his code should be split in two and one part should go to NBOpenGL. > Now he is experiencing some problem with NBOpenGL on windows as you. > > NativeBoost does not work on 64 bits. Yet but igor is really busy > finishing the texteditor (and I can tell you that > he does not have fun there). > > So it is important that you help because we are FULL > and sorry about that but really FULL. > > Ronie will visit us in January and share an office with igor. > > Stef > > > > Hi > > > > CodeCity, the project I am working on is based on NBOpenGL. > > I'd like to start working on it using Pharo 3, but it seems that > NBOpenGL does not work yet with Pharo 3.0. > > > > I downloaded from jenkins the latest image with Pharo 3 and tried to > execute the following code on Windows 7, 64 bits: > > > > GLTTRenderingDemo new openInWorld. > > > > but I get a 'No suitable implementation found for initializing OpenGL > context for your platform'. > > It seems that NBGLContextDriver does not have a subclass for Windows > 64bits. Did I omit something? > > > > Cheers > > Ricky > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 13, 2013

Re: [Pharo-users] Message naming

by Bahman Movaqar

On 11/13/2013 11:39, Bahman Movaqar wrote: > On 11/13/2013 11:13, Bahman Movaqar wrote: >> Let's say I have a method with signature in a language like Java as below: >> gregorianDayToJulianDay(year, month, day) >> >> What could be a proper naming for this method in Smalltalk? I'm a bit >> confused as I'm so used to the concept of methods being "verbs" which >> accept some arguments. >> >> I'd appreciate any help/idea. After reading Sven's reply, I came up with this design. Is it the idiomatic way to handle this problem in Smalltalk: <pseudo-design> class JulianConverter: instance variable: 'day' #toGregorian #toIranian class GregorianConverter: instance variable: 'year month day' #toJulian class IranianConverter: instance variable: 'year month day' #toJulian </pseudo-design> -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

Nov. 13, 2013

Re: [Pharo-users] Message naming

by Sven Van Caekenberghe

On 13 Nov 2013, at 08:52, jtuchel(a)objektfabrik.de wrote: > Bahman, > > Am 13.11.13 08:43, schrieb Bahman Movaqar: >> Let's say I have a method with signature in a language like Java as below: >> gregorianDayToJulianDay(year, month, day) >> >> What could be a proper naming for this method in Smalltalk? I'm a bit >> confused as I'm so used to the concept of methods being "verbs" which >> accept some arguments. >> >> I'd appreciate any help/idea. >> > Thats always hard ;-) > > I suggest a method name starting with 'convert' or 'as'. If you implement the method on a specialized GregorianDate class, you can sure omit the part for what you convert from, in a helper class you need to keep it. > > So let's assume you implement the method on a helper class. Then I'd suggest > > #convertGregorianToJulianYear:month:day: > > If you can change the order of parameters, it is even better (IMO) to make the thing more like Date's newDay:month:year: (or newDay:monthIndex:year). So we end up with: > #convertGregorainToJulianDay:month:year: > > In case you have a specialized GregorianDate class: > GregorianDate>>#asJulianDay:month:year: > > This is of course from a smalltalk perspective. If your goal is to keep it recognizable for Java developers, keep the year:month:date ordering and implement additional methods for the Smalltalk-minded that delegate to the "originals" (or the other way round, that doesn't really matter). > > So this is my train of thoughts about finding a good method name. Others may think completely different. Your comments are valid in the context of a class method, but that is very close to a static global function, which is not very object oriented. It of course depends on the class hierarchy (does it really make sense to both GregorianDate and JulianDate, time and data calculations can be very difficult). So either (GregorianDate newDay: 1 month: 1 year: 2010) asJulianDate or even (Date newDay: 1 month: 1 year: 2010) asJulianDate where I assume the Julian calendar is the default. Sven PS: there is the Chronos library (http://www.squeaksource.com/Chronos/) > HTH > > Joachim > > -- > -- > ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > >

Nov. 13, 2013

Re: [Pharo-users] Message naming

by Bahman Movaqar

On 11/13/2013 11:22, jtuchel(a)objektfabrik.de wrote: > Bahman, > > Am 13.11.13 08:43, schrieb Bahman Movaqar: >> Let's say I have a method with signature in a language like Java as >> below: >> gregorianDayToJulianDay(year, month, day) >> >> What could be a proper naming for this method in Smalltalk? I'm a bit >> confused as I'm so used to the concept of methods being "verbs" which >> accept some arguments. >> >> I'd appreciate any help/idea. >> > Thats always hard ;-) > > I suggest a method name starting with 'convert' or 'as'. If you > implement the method on a specialized GregorianDate class, you can > sure omit the part for what you convert from, in a helper class you > need to keep it. > > So let's assume you implement the method on a helper class. Then I'd > suggest > > #convertGregorianToJulianYear:month:day: Thank you for your suggestions. They look fine but in all of them, somehow, the word "Year" or "Day" becomes part of the message name, which is somehow confusing, isn't it? Or maybe I'm not used to this concept yet. -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

Nov. 13, 2013

Re: [Pharo-users] Message naming

by Bahman Movaqar

On 11/13/2013 11:13, Bahman Movaqar wrote: > Let's say I have a method with signature in a language like Java as below: > gregorianDayToJulianDay(year, month, day) > > What could be a proper naming for this method in Smalltalk? I'm a bit > confused as I'm so used to the concept of methods being "verbs" which > accept some arguments. > > I'd appreciate any help/idea. After reading Joachim's reply, I guess I have to explain a bit more: I'm writing class that converts dates between Gregorian and Iranian (a.k.a. Jalali) calendars. So the design I have (coming from a verb-based perspective) is as follows: <pseudo-design> class: IranianCalendarConverter "The only methods users should ever need to use" class-side: GregorianToIranian(year, month, day) -> returns an integer array (y, m, d) class-side: IranianToGregorian(year, month, day) -> returns an integer array (y, m, d) "Internal methods used for calculation" class-side: IranianDateToJulianDay(year, month, day) -> returns an integer --Julian day class-side: JulidanDayToGregorianDate(day) -> returns an integer array (y, m, d) class-side: GregorianDateToJulianDay(year, month, day) -> returns an integer --Julian day class-side: JulidanDayToIranianDate(day) -> returns an integer array (y, m, d) </pseudo-design> Each of these methods contain about 10-30 lines of code. -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)

Nov. 13, 2013

Re: [Pharo-users] Message naming

by jtuchel＠objektfabrik.de

Bahman, Am 13.11.13 08:43, schrieb Bahman Movaqar: > Let's say I have a method with signature in a language like Java as below: > gregorianDayToJulianDay(year, month, day) > > What could be a proper naming for this method in Smalltalk? I'm a bit > confused as I'm so used to the concept of methods being "verbs" which > accept some arguments. > > I'd appreciate any help/idea. > Thats always hard ;-) I suggest a method name starting with 'convert' or 'as'. If you implement the method on a specialized GregorianDate class, you can sure omit the part for what you convert from, in a helper class you need to keep it. So let's assume you implement the method on a helper class. Then I'd suggest #convertGregorianToJulianYear:month:day: If you can change the order of parameters, it is even better (IMO) to make the thing more like Date's newDay:month:year: (or newDay:monthIndex:year). So we end up with: #convertGregorainToJulianDay:month:year: In case you have a specialized GregorianDate class: GregorianDate>>#asJulianDay:month:year: This is of course from a smalltalk perspective. If your goal is to keep it recognizable for Java developers, keep the year:month:date ordering and implement additional methods for the Smalltalk-minded that delegate to the "originals" (or the other way round, that doesn't really matter). So this is my train of thoughts about finding a good method name. Others may think completely different. HTH Joachim -- -- â¨----------------------------------------------------------------------- â¨Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de â¨Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Nov. 13, 2013