November 2013 - Pharo-users

Re: [Pharo-users] CogVM arguments in Win32

by Igor Stasenko

On 13 November 2013 12:02, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com>wrote: > Thanks a lot Torsten! > > I'll invest the whole morning tomorrow in trying to get a little bit more > of this to work. > > If I don't succeed... there are lots of very good restaurants in > Barcelona, Igor ;) > > i can imagine :) I hope i will be able come there once more one day. Barcelona is very beautiful city. :) > 2013/11/13 Torsten Bergmann <astares(a)gmx.de> > >> 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... >> >> > > > -- > Bernat Romagosa. > -- Best regards, Igor Stasenko.

Nov. 13, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by Igor Stasenko

On 13 November 2013 11:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > JB can you read and reply to this mail? > > 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? > > > for now probably, because if you that is the one the most interested guy > in that does not have the time to understand why others that > do not need 3D should do it. NBOpenGL was a side project to give a try of > busy people too. I'm sorry to say that > but we cannot be on all fronts especially when they are changing. > > So can you tell us if you see what changed between 2 and 3. I have no idea. > > NBOpenGL needs to be updated to sync with changes in NB about NBExternalStructure. Right now it cannot even be loaded into 3.0. But update is simple (i think JB did that already, just not published?). > I have already looked at Roassal 3d, but it was not easy to separate the > API from the code. > > > Strange because even me I could see that the shadder code should not be in > Roassal 3D but in NBOpenGL :). > Because Roassal 3d should not be about shadder but about 3D. > > 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). > > > Yes they changed the API and deprecated the old way of doing it. > > So, I would really appreciate if that API would find its way from Roassal > to NBOpenGL and I could use it for CodeCity. > > > See below > > 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. > > > Three remarks: > - I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL > - I'm not sure that doing 3d without investing a bit in the underlying > technology is wise. Because you will be always relying > on other people and probably frustrated when things are not working. > - Since JB does not know how to communicate here is what he did for fun > instead of pushing MoosePython :) > a renderer to video to videos stream for openGL -> MKV, mp4 based one > ffmpeg). The code is openGL extra. As an example you > can get > https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk > > Now again if nobody builds a jun like library in Pharo it will not exist. > > Stef > > > > 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" >> > > > -- Best regards, Igor Stasenko.

Nov. 13, 2013

Re: [Pharo-users] CogVM arguments in Win32

by Igor Stasenko

On 13 November 2013 10:25, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com>wrote: > 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? > > This is easy. Just make a subclass of NBExternalStructure, define its fields in #fieldsDesc method (see example subclass). Create it using #new, or #externalNew depending if structure should be non-moving in memory for the rest of its life (but i think its needed only at the moment of call, so #new should work), fill it with proper values, and then pass it to that function. Just make sure that argument type PNOTIFYICONDATA changed to class name of your structure in function signature. Also, note that there is two Shell_NotifyIcon functions under the hood: Shell_NotifyIconA Shell_NotifyIconW the 'A' stands for 'ascii', and 'W' stands for 'wide', this is how windows manages strings and characters/unicode. For 'A' functions TCHAR == char (1byte) for 'W' functions TCHAR == unsigned short (2bytes) that means the definition and size of PNOTIFYICONDATA is different depending on what function you going to be using. 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? > hehe.. this is a typical for everything in windows: many, even basic things require passing and filling various structures with many different fields, and you may find that to initialize fields of one structure, you often need to create another one and initialize it first :) > > > 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. > -- Best regards, Igor Stasenko.

Nov. 13, 2013

Re: [Pharo-users] PetitParser and external streams

by Federico.Balaguer

Thanks Norbert for your kind reply. My only reminding question is about the input. PetitStream are made from the contents of another stream. So, if I have a readStream on a file and I convert it to PetitStream, it will end up loading the entire content of the file on memory. Could it be possible to use a "LazyPetitStream" that is getting the content from the original stream incrementally? Thanks! Federico -- View this message in context: http://forum.world.st/PetitParser-and-external-streams-tp4721440p4721691.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 13, 2013

Re: [Pharo-users] Message naming

by Sven Van Caekenberghe

Hi Bahman, On 13 Nov 2013, at 09:19, Bahman Movaqar <Bahman(a)BahmanM.com> wrote: > 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> There is not necessarily a right and a wrong way. Design is hard to explain, I am not going to try. Sorry ;-) But please do have a look at the Chronos library, it even has a PersianCalender, among many others. This is the class comment: [Chronos] All code (classes and methods, and all associated documentation,) distributed as part of the Chronos Date/Time library are Â¬Â© Copyright 2005-2006 by Alan L. Lovejoy. All Rights Reserved. Usage is controlled by the Chronos License (which is included in the distribution as the contents of the file {chronos-license.txt}, and is also available from the Chronos web site {http://www.chronos-st.org/License.html}) PersianCalendar Concept: PersianCalendar implements the arithmetical version of the Persian Calendar. There is also an astronomical version of the Persian Calendar, which some authorities claim is the one actually used in Iran, although other authorities claim otherwise. Chronos does not currently provide implementations of any astronomical calendars. The astronomical version of the Persian Calendar will (eventually) be implemented by class named AstronomicalPersianCalendar, whose registration key will be #'Persian-Astronomical'. For any and all discussion of what a 'Calendar' is conceptually, how an instance of a Calendar can and/or should be used, the general implementation requirements for subclasses of Calendar, or the architectural requirements and responsibilities of Calendar instances with respect to the rest of the Chronos Date/Time Library, please refer to the documentation of class Calendar. The remainder of this text discusses the specific nature of the Persian Calendar itself (and its implementation by this class,) and assumes that the reader has already become familiar with all the concepts and terminology documented in class Calendar. The Persian Calendar (as implemented here) is an arithmetical, solar calendar. A solar calendar is one that attempts to match the (average) length of its years to that of mean solar years. Epoch Date The epoch date of the Persian Calendar, 0001-01-01 [Persian], corresponds to 0622-03-22 [Gregorian] and to 0622-03-19 [Julian]. The Julian Date of the epoch of the Persian Calendar is 1,948,320.50 (midnight.) The epoch date of the Persian Calendar is the vernal equinox of the year in which the "hijra" of Mohammed to Medina occurred ("hijra" means "flight from danger.") The era of the Persian Calendar is called "Anno Persico" or "Anno Persarum" (AP)--which is Latin for "In the Year of Persia/the Persians." Time-of-Day Clock Modernly, midnight is both the zero-point of the time-of-day clock and also the initial moment of the day. However, such has not always been the case for all users of the Persian Calendar. {PersianCalendar clock today} {PersianCalendar clock now} Year Numbering Policy The Persian Calendar uses "zeroless ordinal" year numbering. This means that the epoch year is an ordinal number whose value is 1, and the year that immediately precedes the year 1 is the year -1. Leap Year Rule According to Birashk [A. Birashk, "A Comparative Calendar of the Iranian, Muslim Lunar, and Christian Eras for Three Thousand Years," Mazda Publishers (in association with Bibliotheca Persica,) Costa Mesa, CA, 1993], the arithmetical form of the Persian Calendar uses the following rather complicated leap year rules: There is a master cycle of 2820 years, during which 683 years are leap years. Each standard year contains 365 days, and each leap year contains 366 days, so the master 2820-year cycle contains 1,029,983 days [(2820 * 365) + 683 = 1,029,983]. Based on the current mean length of the tropical year and solar day, there are 1,029,983.00118 days in 2820 tropical years. So, were it not for the fact that a) the length of the tropical year and the length of a mean solar day is slowly changing, and b) the length of the tropical year (which is defined by the duration between winter solstices) is not the same as the length of the spring equinoctial year (which is defined by the duration between vernal equinoxes,) it would be fair to say that the Persian arithmetical calendar deviates from the length of a year by only 101.952 minutes in 2820 years. But for those (and other) caveats, the Persian arithmetical calendar would slip from perfect alignment with the tropical year by only one day every 39,829.68 years--which is astounding accuracy, in spite of the caveats. Within each 2820-year cycle, there are 22 subcycles--the first 21 each contain 128 years, and the 22nd (final) subcycle contains 132 years [2820 = 21 * 128 + 132]. Each 128-year subcycle contains one 29-year sub-subcycle (the first,) followed by three 33-year sub-subcycles [128 = 29 + (3 * 33)]. Each 132-year subcycle contains one 29-year sub-subcycle (the first,) followed by two 33-year sub-subcycles, followed by one 37-year sub-subcycle [132 = 29 + (2 * 33) + 37]. A year in a sub-subcycle (whether it contains 29, 33 or 37 years) is a leap year if the ordinal index of the year within the cycle satisfies the following two predicate tests: 1) it's greater than 1, and 2) the remainder after dividing it by 4 is 1 (so the first year in sub-subcyle is never a leap year; the first leap year is the fifth year in the sub-subcycle.) Thus, a 29-year sub-subcycle has 7 leap years, a 33-year sub-subcycle has 8 leap years, and a 37-year sub-subcycle has 9 leap years (Note: the last year of a sub-subcycle is always a leap year, since 29, 33 and 37 all result in a remainder of 1 when divided by 4) [21 * (7 + (3 * 8)) + (7 + (2 * 8) + 9) = 683]. The base year of the 2820 cycle of years is NOT the Persian year zero or 1, however. The base year of the 2820-year cycle of years is the Persian year 475 (which starts on 21 March 1096 [Gregorian] or 15 March 1096 [Julian].) However, to facilitate the use of modular arithmetic, the Chronos implementation uses Persian year 474 as the zeroeth year of the 2820-year cycle. Algorithm of Predicate Function that answers true if a <persianYear> is a leap year (input arg=<persianYear>): 1. If <persianYear> >= 1 then set <cardinalYear> to <persianYear> - 1; else set <cardinalYear> to <persianYear>; end 2. Set <dividend> to <cardinalYear> - 473. 3. Set <year> to (dividend mod 2820) + 474. 4. Return (((<year> + 38) * 682) mod 2816) < 682 Month Structure Month Days In Month Standard Year/Leap Year 1: Farvardin 31/31 2: Ordibehesht 31/31 3: Xordad 31/31 4: Tir 31/31 5: Mordad 31/31 6: Shahrivar 31/31 7: Mehr 30/30 8: Aban 30/30 9: Azar 30/30 10: Dey 30/30 11: Bahman 30/30 12: Esfand 29/30 Days In Year 365/366 The semantic month-key of a month is the same as the month's (English) name (as given here.) Pretty deep, right ? HTH, Sven Yes, the main website is down, but you should be able to load the code in Pharo 2.0 using the configuration. > -- > 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 kilon alios

Thats not only the Pharo, the Squeak, way, the Python way, the Ruby way ..... its the logical way GregorianDate >> toJulian You have a class then you have a method . You want to extend your method ? why increase the size of method ? You just create a new class for it. I have 3 rules when I code 1) Keep it small 2) Keep it simple 3) Keep it obvious Also I cant recommend this book highly enough, its not only the best book I have read, its a goldmine of concentrated wisdom. No vague theories, no assumptions, just a bombarbment of practical examples -> http://www.amazon.com/Smalltalk-Best-Practice-Patterns-Kent/dp/013476904X it wont show you just proper naming it will show you everything. Its the kind of book that you will keep coming back to. This something that every coder should have. and yes Java is doing it wrong, its doing it very wrong. On Wed, Nov 13, 2013 at 10:19 AM, Bahman Movaqar <Bahman(a)bahmanm.com> wrote: > 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 StÃ©phane Ducasse

did you check acancagua (unit and time) or chronos (more complete calendar) package Stef On Nov 13, 2013, at 9:19 AM, Bahman Movaqar <Bahman(a)BahmanM.com> wrote: > 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] How to change background color

by Sergi Reyner

Ben, could you elaborate a bit on: add support for color on AbstractWidget > change a bit the way MorphicAdapters are built to take this color in account > I havenÂ´t quite figured out yet how do all the pieces fit together. It may be due to lack of caffeine though :) I have noticed that color sort of works... for example, you can inspect a SpecWindow, send it (self color: Color red) and the window will indeed change color, but as soon as you click on it it goes back to the default grey. Cheers, Sergi

Nov. 13, 2013

Re: [Pharo-users] CogVM arguments in Win32

by Bernat Romagosa

Thanks a lot Torsten! I'll invest the whole morning tomorrow in trying to get a little bit more of this to work. If I don't succeed... there are lots of very good restaurants in Barcelona, Igor ;) 2013/11/13 Torsten Bergmann <astares(a)gmx.de> > 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... > > -- Bernat Romagosa.

Nov. 13, 2013

Re: [Pharo-users] NBOpenGL on Pharo 3.0

by StÃ©phane Ducasse

JB can you read and reply to this mail? > 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? for now probably, because if you that is the one the most interested guy in that does not have the time to understand why others that do not need 3D should do it. NBOpenGL was a side project to give a try of busy people too. I'm sorry to say that but we cannot be on all fronts especially when they are changing. So can you tell us if you see what changed between 2 and 3. I have no idea. > I have already looked at Roassal 3d, but it was not easy to separate the API from the code. Strange because even me I could see that the shadder code should not be in Roassal 3D but in NBOpenGL :). Because Roassal 3d should not be about shadder but about 3D. > 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). Yes they changed the API and deprecated the old way of doing it. > So, I would really appreciate if that API would find its way from Roassal to NBOpenGL and I could use it for CodeCity. See below > 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. Three remarks: - I know that jean-baptiste worked on moving part of roassal3d to NBOpenGL - I'm not sure that doing 3d without investing a bit in the underlying technology is wise. Because you will be always relying on other people and probably frustrated when things are not working. - Since JB does not know how to communicate here is what he did for fun instead of pushing MoosePython :) a renderer to video to videos stream for openGL -> MKV, mp4 based one ffmpeg). The code is openGL extra. As an example you can get https://www.dropbox.com/sh/uyli3tx3drendvj/qzA_Hy0jnk Now again if nobody builds a jun like library in Pharo it will not exist. Stef > 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