Re: [Pharo-users] global exception handler mechanism
On 5 February 2018 at 10:17, Marcus Denker <marcus.den...@inria.fr> wrote: > Hello, > > The Sunit-Debugger does a stack search on startup to find the test related > exception. > > It might be good to do it better, especially as the debug process starts > from the exception > I might be a good idea to actually keep a reference to it. > > Would there be any downside of Exception>>debug passing a reference to the > Debugger? > > Marcus > > > > On 2 Feb 2018, at 17:19, Peter Uhnák <i.uh...@gmail.com> wrote: > > > > Hi, > > > > is there a way to install a global handler for exceptions? > > > > Right now if I want to log all exceptions, I use approach from ShoreLine > and create a PreDebugAction which is activated when any "unhandled" > exception occurs. > > > > That would be good enough, however the Debugger has zero knowledge of > the exception that is actually occuring, as Exception>>debug passes on only > the title. So if I want to get back to the original exception and maybe log > it with beacon, I need to do a lot of stack and context shenanigans: > > > > MyPreDebugAction>>logException > > MyLogger > > runDuring: [ (debugger session interruptedProcess > suspendedContext stack > > detect: [ :context | context receiver > isKindOf: Exception ]) receiver emit ] > > > > > > Is there a better way to approach this? > if you own a process (you creating it) , then it is just a piece of cake, just make a topmost block with #on:do: if you don't own a process (suppose you wanna watch already existing one) , it can be done by injecting own context at the bottom of stack , well, unless there are exception handler(s) upper, that catch any exception(s) before you can see them. I think a much better way would be to watch exceptions even before they being handled, for this, i would override Exception>>#signal and add some kind of logging or notification .. well, anything you see fit. That's, of course, a kind of dangerous, be careful. Do not attempt to throw new exceptions while processing just signaled one, else you'll get infinite recursion :) > > > Thanks, > > Peter > > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] Athens error
i think it will help more if you reveal the full stack trace with actual exception.. IIRC you can do it by clicking on errorneous morph and in its menu pick the stack trace. On 16 December 2017 at 23:29, Hilaire <hila...@drgeo.eu> wrote: > Hi, > > With DrGeo built on image Pharo7.0-64bit-e41f921 Athens error shows up on > the canvas (screenshot). > > The drgeo dev. environment based on the older Pharo7.0-64bit-f82fc36 image > does not have this error with the same VM. > > The DrGeo build removes some pharo package but it is unlikely to produce > such error, or so? > > -- > Dr. Geo > http://drgeo.eu > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] X11 options on Ubuntu VM / Athens rendering problems
On 1 October 2017 at 10:26, Hilaire <hila...@drgeo.eu> wrote: > All these difficulties are good argument to get the appropriate > libcairo/libpng shipped with the Linux VM, as done with Windows and MacOSX > VM > > Nah, in my case, there's nothing that can be lableled as "Pharo fault". It is definitely a linux/ubuntu ecosystem fault. - by not providing parallel updates for 32 & 64 bit variant of same library. > Hilaire > > > Le 30/09/2017 à 21:58, Igor Stasenko a écrit : > >> Sure. But i didn't done much, so there's nothing to appriciate yet :) >> But i want to help, if it won't require reinstalling OS, because i need >> my machine in working condition almost 24/7.. so i cannot take too much >> risk with it :( >> > > -- > Dr. Geo > http://drgeo.eu > > > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] X11 options on Ubuntu VM / Athens rendering problems
On 30 September 2017 at 17:51, J.F. Rick <s...@je77.com> wrote: > Hi Igor et al., > > thanks for taking a look at this. I appreciate it a lot. I've been swamped > with work et al. but I'm back. If I understand it correctly, Igor is still > fighting with drivers to make it work on his system. Let me know when you > want me to try something. > > Sure. But i didn't done much, so there's nothing to appriciate yet :) But i want to help, if it won't require reinstalling OS, because i need my machine in working condition almost 24/7.. so i cannot take too much risk with it :( Cheers, > > Jeff > > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] X11 options on Ubuntu VM / Athens rendering problems
On 29 September 2017 at 22:05, Hilaire <hila...@drgeo.eu> wrote: > libcairo2:amd64 1.15.2-0intel1 is clearly not from the official repository. > > See on my ubuntu17.04: > > hilaire@PCHome:~$ dpkg -l | grep libcairo2 > ii libcairo2:amd64 1.14.8-1 amd64Cairo 2D vector graphics library > ii libcairo2:i386 1.14.8-1 i386 Cairo 2D vector graphics library > ii libcairo2-dev 1.14.8-1 amd64Development files for the Cairo 2D > graphics library > > > If you can wipe it out, you may sort out. > > most probably it is due to my attempts to make my hybrid graphics setup work.. i bought this laptop year ago and then figured out, that there are issues with X11 and kernel drivers that prevents using both video cards on board.. and installing latest & finest didn't changed much. -- Best regards, Igor Stasenko.
Re: [Pharo-users] X11 options on Ubuntu VM / Athens rendering problems
On 29 September 2017 at 11:23, Hilaire <hila...@drgeo.eu> wrote: > Beside the official ones, are you using alternate repositories? It can > become a hell. > > In your posting, a Thoera dependency appeared... > > it looks like there's an error in dependency spec. because i have 64-bit cairo installed, and uninstalling theora drags half of the desktop stuff after itself.. oh.. looks like i found why: sudo dpkg -i libcairo2_1.14.8-1_i386.deb Selecting previously unselected package libcairo2:i386. (Reading database ... 541684 files and directories currently installed.) Preparing to unpack libcairo2_1.14.8-1_i386.deb ... De-configuring libcairo2:amd64 (1.15.2-0intel1) ... Unpacking libcairo2:i386 (1.14.8-1) ... dpkg: error processing package libcairo2:i386 (--install): package libcairo2:i386 1.14.8-1 cannot be configured because libcairo2:amd64 is at a different version (1.15.2-0intel1) dpkg: error processing package libcairo2:amd64 (--install): package libcairo2:amd64 1.15.2-0intel1 cannot be configured because libcairo2:i386 is at a different version (1.14.8-1) Processing triggers for libc-bin (2.24-9ubuntu2.2) ... Errors were encountered while processing: now where the heck i can find binary of appropriate version libcairo2:i386 1.15.2 (googling doesn't helps) > Hilaire > > Le 28/09/2017 à 19:51, Igor Stasenko a écrit : > >> >> I got libsdl and libcairo 32bits installed fine on 64bits Ubuntu >> 17.04. >> >> weird.. >> > > -- > Dr. Geo > http://drgeo.eu > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] [Demo] Creating Bloc Widgets with Pharo
Stephan , you said you cannot replace the last one in the video. I think you can have an easy solution: you should treat a pane that you are currently over - the one you are going to replace, so if you drag over something which is not placeholder, then it should automatically be shifted and replaced by placeholder. Cheers :) On 29 September 2017 at 00:56, stephan <step...@stack.nl> wrote: > On 28-09-17 21:07, Stephane Ducasse wrote: > >> For example why a BlElement cannot get >> invisible and visible in addition to visibility: BlVisibility visible. >> > > It can, and if we do that systematically we end up with a BlElement with a > thousand methods. There are so many aspects that an element might need to > handle. Handling children, layout, styling, drawing, fonts, events, > visibility. Where should the border be? > > One thing I noted is that in Bloc we don't have a way to decide where to > add a dropped element in a parent that has a specified layout. In Morphic > that is also a responsibility of the layout. > > Stephan > > > > > > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] X11 options on Ubuntu VM / Athens rendering problems
On 28 September 2017 at 12:43, Hilaire <hila...@drgeo.eu> wrote: > Hi Igor, > > I got libsdl and libcairo 32bits installed fine on 64bits Ubuntu 17.04. > > weird.. > What is your ubuntu system? > > cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=17.04 DISTRIB_CODENAME=zesty DISTRIB_DESCRIPTION="Ubuntu 17.04" > Hilaire > > > > Le 28/09/2017 à 01:22, Igor Stasenko a écrit : > >> something in my installation are in conflict with 32-bit version of >> cairo.. that's weird.. >> but unmet dependencies/dependency conflict resolution of linux .deb >> packages is not my strong side. >> So, it would be nice if someone could help how to proceed with that. >> > > -- > Dr. Geo > http://drgeo.eu > > > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] X11 options on Ubuntu VM / Athens rendering problems
imo, best what could be done is to forget about 32-bit version and use 64-bit VM & libs, to avoid problems like above. but for that, i need a 64-bit VM/image pair for a start, because one that you gave me is 32-bit.. and hence drags all the trouble with all this .so dependency zoo.. -- Best regards, Igor Stasenko.
Re: [Pharo-users] X11 options on Ubuntu VM / Athens rendering problems
apparently the SDL2 library is not in LD search path ldd libSDL2DisplayPlugin.so linux-gate.so.1 => (0xf77e9000) libSDL2-2.0.so.0 => not found libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf75dd000) /lib/ld-linux.so.2 (0x56573000) so it simply doesn't starts, so i installed sudo apt-get install libsdl2-2.0-0:i386 but then i found that i need to install 32-bit version of cairo as well.. but alas.. here is where i stuck: sudo apt-get install libcairo2:i386 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libtheora0 : Depends: libcairo2 (>= 1.2.4) but it is not going to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. something in my installation are in conflict with 32-bit version of cairo.. that's weird.. but unmet dependencies/dependency conflict resolution of linux .deb packages is not my strong side. So, it would be nice if someone could help how to proceed with that. On 28 September 2017 at 01:41, Igor Stasenko <siguc...@gmail.com> wrote: > okay, first, i have to change the path to SDL2 library, because on my > machine it's in > /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 > but there's another trouble: > browsing is incredibly slooow... > First, i used finder to look for 'libSDL2-2.0.so.0' in sources. it took > like 2 minutes to go through first few classes with starting A letter in > their name. > Then i lost temper, interrupted it and decided to browse into SDL bindings > manually - clicked on OSWindow-SDL2 package... and its still 100% CPU and > didn't opened > while i typing this whole message. > > What is going on? Are .sources file corrupted or what? > > > > On 28 September 2017 at 01:27, Igor Stasenko <siguc...@gmail.com> wrote: > >> >> >> On 27 September 2017 at 22:54, Stephane Ducasse <stepharo.s...@gmail.com> >> wrote: >> >>> Igor I will share the dropbox for you. >>> What would be great is to port the code of clement to Pharo 6.1 or >>> even 70 to check SDL20 >>> Esteban was integrating some of the code of ronie. >>> >>> Downloading.. >> Would be nice, if someone could give me short directions how to test it , >> what to run and what to expect. Because i am clearly was out of context for >> too long. >> >> >>> Stef >>> >>> >>> On Wed, Sep 27, 2017 at 1:05 PM, Igor Stasenko <siguc...@gmail.com> >>> wrote: >>> > i'm on ubuntu right now, so i could help with trying & testing things >>> and/or >>> > diagnosing problems. Just tell me what to do >>> > >>> > >>> > -- >>> > Best regards, >>> > Igor Stasenko. >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
Re: [Pharo-users] X11 options on Ubuntu VM / Athens rendering problems
okay, first, i have to change the path to SDL2 library, because on my machine it's in /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 but there's another trouble: browsing is incredibly slooow... First, i used finder to look for 'libSDL2-2.0.so.0' in sources. it took like 2 minutes to go through first few classes with starting A letter in their name. Then i lost temper, interrupted it and decided to browse into SDL bindings manually - clicked on OSWindow-SDL2 package... and its still 100% CPU and didn't opened while i typing this whole message. What is going on? Are .sources file corrupted or what? On 28 September 2017 at 01:27, Igor Stasenko <siguc...@gmail.com> wrote: > > > On 27 September 2017 at 22:54, Stephane Ducasse <stepharo.s...@gmail.com> > wrote: > >> Igor I will share the dropbox for you. >> What would be great is to port the code of clement to Pharo 6.1 or >> even 70 to check SDL20 >> Esteban was integrating some of the code of ronie. >> >> Downloading.. > Would be nice, if someone could give me short directions how to test it , > what to run and what to expect. Because i am clearly was out of context for > too long. > > >> Stef >> >> >> On Wed, Sep 27, 2017 at 1:05 PM, Igor Stasenko <siguc...@gmail.com> >> wrote: >> > i'm on ubuntu right now, so i could help with trying & testing things >> and/or >> > diagnosing problems. Just tell me what to do >> > >> > >> > -- >> > Best regards, >> > Igor Stasenko. >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
Re: [Pharo-users] X11 options on Ubuntu VM / Athens rendering problems
On 27 September 2017 at 22:54, Stephane Ducasse <stepharo.s...@gmail.com> wrote: > Igor I will share the dropbox for you. > What would be great is to port the code of clement to Pharo 6.1 or > even 70 to check SDL20 > Esteban was integrating some of the code of ronie. > > Downloading.. Would be nice, if someone could give me short directions how to test it , what to run and what to expect. Because i am clearly was out of context for too long. > Stef > > > On Wed, Sep 27, 2017 at 1:05 PM, Igor Stasenko <siguc...@gmail.com> wrote: > > i'm on ubuntu right now, so i could help with trying & testing things > and/or > > diagnosing problems. Just tell me what to do > > > > > > -- > > Best regards, > > Igor Stasenko. > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] X11 options on Ubuntu VM / Athens rendering problems
i'm on ubuntu right now, so i could help with trying & testing things and/or diagnosing problems. Just tell me what to do -- Best regards, Igor Stasenko.
Re: [Pharo-users] type checking in Smalltalk
On 31 March 2017 at 21:34, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > > On 31 Mar 2017, at 19:38, Dimitris Chloupis <kilon.al...@gmail.com> > wrote: > > > > > > On Fri, 31 Mar 2017 at 19:13, Sven Van Caekenberghe <s...@stfx.eu> > wrote: > > if you copy/paste something you should give a reference > > > > > > I did not copy paste anything, 100 % mine. What part you think it's copy > ? > > Ah, sorry then, the formatting seemed to suggest it came from somewhere > else. > > BTW, I don't think the hybrid part is a real thing. > > Although I understand that static typed languages like C, C++, Java and so > many others have their place and use, people in those languages spend an > awful amount of time and code dealing with the types they love so much. The > modern static languages with all their magic are even worse. And even in a > nice static typed program that compiles with no warnings, there are still > dynamic errors lurking everywhere. The world cannot be defined in a static > way. > > The dynamic type errors that you get in Pharo during development are 95% > plain logic errors, once you fix those and write some unit tests, a Pharo > program is just as stable and reliable as anything else that is well > written, tested and debugged. > > And I love Igor's "Don't ask, tell" idea - right on target. > > Hey, hey.. These words, originally, definitely are not mine.. It is something i learned, being among wise people of smalltalk family. > Anyway, that is my personal opinion, I don't want to convince you. > > Sven > -- Best regards, Igor Stasenko.
Re: [Pharo-users] why is adding instance variables so slow?
i don't see much difference comparing to old implementation of #becomeForward: the only issue is that #allInstances could report same instance twice first, it will find an old instance (that is forwards to new one) and so, add it to results array, and then walking the heap further will find a new version of same instance. That's why , it think #allInstances should use IdentitySet-behavior to mitigate such problem, and always look if there's already same object captured to avoid reporting it twice. Or else we can declare it as a feature and warn users of #allInstances that they could have duplications, so in case if it important to them, they could always do 'allInstances asIdentitySet' But again, this is s orthogonal to adding instance variables to class... maybe we should rename the topic instead and speak about #allInstances behavior? :) On 14 April 2017 at 12:09, teso...@gmail.com <teso...@gmail.com> wrote: > Hi, I think the problem was not clearly explained. This is the scenario > that is problematic. > This scenario does not happen in the new Spur implementation of > forwarding, but I think is happening in the old one. > > 1. You have, let's say 3 instances of ClassA. > 2. You add a new instance variable to ClassA. It produces >2a. A new ClassAv2 is created with the instances variables of ClassA > and the newone >2b. 3 Instances of ClassAv2 are created >2c. The values of the instance variables of ClassA are copied to the > ones in ClassAv2 (the ones missing are left in nil). >2d. The 3 instances of ClassA are becomed forward to the 3 instances of > ClassAv2 >2e. The ClassA is becomed forward ClassAv2 > > 3. You add a new instance variable to ClassAv2. It produces >3a. A new ClassAv3 is created with the instances variables of ClassAv2 > and the newone >3b. 3 Instances of ClassAv3 are created >3c. The values of the instance variables of ClassAv2 are copied to the > ones in ClassAv3 (the ones missing are left in nil). >3d. The 3 instances of ClassAv2 are becomed forward to the 3 instances > of ClassAv3 >3e. The ClassAv2 is becomedFormeward ClassAv3 > > 4. All the instances of ClassAV3 have the correct format and everything > works. > > What is the problem: > === > > - When you do the first add instance variable, the old instances (the one > from ClassA) which are smaller (has 1 instance variable less) > have its class changed (after you perform a become of ClassA to ClassAv2). > So if you try to use them everything will explode, because you will trying > to access an instance variable that does not exists. > These instances are not referenced by anyone, however if you perform a > ClassAv2>>allInstances you will find them. So if you modify the class > adding two variables, one after another the second time > you will be accessing the invalid instances. > > > Considering the differences in the Become implementation > > > However, the main difference is the implementation of the become forward. > Let's start with the new implementation, as it has not problems. > > When you do a become forward, from object a to b, the primitive replaces > the object a with a forwarder to b. > When this forwarded is accessed the references to it are rewrited. > If the objects are the same size (not this scenario) the object b replaces > object a. It does not produces an error because the old. > In the become forward the old instances are not keeped. > > In the old implementation the whole image is scanned, changing the > references to the old instances, replacing with references to the new > instances. > The old instances are not removed, just kept there to let the GC do its > work. > Again if the objects are the same size there is special behavior. > > I hope know the problem is better explained > > Cheers, > Pablo > > > > On Fri, Apr 14, 2017 at 10:50 AM, Igor Stasenko <siguc...@gmail.com> > wrote: > >> >> >> On 14 April 2017 at 10:19, Stephane Ducasse <stepharo.s...@gmail.com> >> wrote: >> >>> But I do not get how doing that would handle the old instances? >>> Because you want to migrate the old instances. >>> >>> >> +1 >> there are no such thing as 'bad zombies', if they are there, it means you >> either don't care about migrating data >> or again, don't care about doing #becomeForward-ing them properly. >> In any case i don't see how GC could help to fix these issues. You either >> have consistency or don't have it, >> and GC cannot do anything magical to fix it. >> >> >> >>> Stef >>> >>> On Wed, Apr 1
Re: [Pharo-users] Export MongoDB to sql format
On 13 April 2017 at 22:23, Esteban Lorenzano <esteba...@gmail.com> wrote: > > On 13 Apr 2017, at 19:26, Asbath Sama biyalou via Pharo-users < > pharo-users@lists.pharo.org> wrote: > > > *From: *Asbath Sama biyalou <asamabiya...@yahoo.com> > *Subject: **Export MongoDB to sql format* > *Date: *13 April 2017 at 19:26:25 GMT+2 > *To: *Pharo users users <pharo-users@lists.pharo.org> > > > Hello Everyone. > > I think this is not the right place for this question. But I am doing a > work with Pharo. > > I use MongoDB with Voyage. But I am asked to export my database in sql > format. > > I want to know if there is a way to export mongoDB in sql. > > > there is not. > a nosql database will have problems to export its data as sql. > of course it can be done (as everything), but it is a manual task :S > > This sort of questions most strangest ones , that i always wonder.. Like people who buying microwave asking: cool , now how i could fit a coal burner to it? Why I mean if you need your traditional oven, they why even bother to buy a microvawe in a first place? cheers, > Esteban > > > Thanks. > > > Asbath > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] why is adding instance variables so slow?
On 12 April 2017 at 14:17, Guillermo Polito <guillermopol...@gmail.com> wrote: > > > On Wed, Apr 12, 2017 at 11:35 AM, Denis Kudriashov <dionisi...@gmail.com> > wrote: > >> >> 2017-04-12 10:55 GMT+02:00 Guillermo Polito <guillermopol...@gmail.com>: >> >>> PharoClassInstaller>>migrateClasses: old to: new using: >>>> anInstanceModification >>>> instanceModification := anInstanceModification. >>>> old ifEmpty: [ ^ self ]. >>>> [ >>>> 1 to: old size do: [ :index | >>>> self updateClass: (old at: index) to: (new at: index)]. >>>> old elementsForwardIdentityTo: new. >>>> " Garbage collect away the zombie instances left behind in garbage >>>> memory in #updateInstancesFrom: " >>>> " If we don't clean up this garbage, a second update would revive them >>>> with a wrong layout! " >>>> " (newClass rather than oldClass, since they are now both newClass) " >>>> Smalltalk garbageCollect. >>>> ] valueUnpreemptively >>>> >>>> Commenting garbage collection here increases performance 10 times. >>>> Then commenting class update loop increases performance 3 times more. >>>> But this loop is required. It adopts all instances of old class to new one. >>>> And time here spent in #allInstances method. >>>> >>>> Can we remove manual garbage collection here? Why it is needed? >>>> >>> >>> Well, there is the comment that explains it and makes pretty good sense. >>> >> >> But is does not explain why these bad zombies exist. We investigates >> possible reasons and could not reproduce them. We will try remove garbage >> collection here in Pharo 7 >> > > No, this will break stuff! I'll try to explain what does it mean by zombie > instances to make some sense: > > - Imagine that you have class A + 10 instances of A. > > - We add an instance variable to A. > - this means the class builder will generate class A' that is the new > version of A. > - then, it migrates all instances of A to class A'. > This migration is not magic: > - 10 new instances of A' are created > - the state is migrated from the instances of A to A' > - each instance of A is becomed into its corresponding instance of > A' > - finally we become class A into A' > This step will make that old instances of A now have: > - the old format > - but point to the new class A > > If we do not garbage collect, this means that doing > > A allInstances > > will return not only the new 10 instances of A, but the old instances of > A'. > And that will break LOOOTS of stuff. > if you run #allInstances and in between you will trigger adding instance var & GC etc etc.. you'll have everything broken.. because there are things didn't meant to work in certain scenarios. IIRC allInstances is highly dependns on NOT having full GC while doing it, and that's why all loops that doing it is highly conservative & cautious about creating new objects while iterating over heap. That's the nature how #allInstance works, and you could have a tons of issues with it regardless , if you do full GC manually, or it triggered by VM itself. So, this is nothing to do with migrating instances of class. -- Best regards, Igor Stasenko.
Re: [Pharo-users] why is adding instance variables so slow?
On 14 April 2017 at 10:19, Stephane Ducasse <stepharo.s...@gmail.com> wrote: > But I do not get how doing that would handle the old instances? > Because you want to migrate the old instances. > > +1 there are no such thing as 'bad zombies', if they are there, it means you either don't care about migrating data or again, don't care about doing #becomeForward-ing them properly. In any case i don't see how GC could help to fix these issues. You either have consistency or don't have it, and GC cannot do anything magical to fix it. > Stef > > On Wed, Apr 12, 2017 at 1:26 PM, Denis Kudriashov <dionisi...@gmail.com> > wrote: > >> >> 2017-04-12 13:17 GMT+02:00 Guillermo Polito <guillermopol...@gmail.com>: >> >>> 1) each instance of A is becomed into its corresponding instance of A' >>> 2) finally we become class A into A' >>> This step will make that old instances of A now have: >>> - the old format >>> - but point to the new class A >>> >> >> step 1) ensures that there are no instances of class A anymore. >> Check following script: >> >> c1 := Class1 new. >> c2 := Class2 new. >> c1 becomeForward: c2. >> Class1 allInstances "=> #()". >> >> >> And full migration is executed in high priority uninterrupted process to >> ensure that between 1) and 2) nobody will instantiate Class1 >> >> > -- Best regards, Igor Stasenko.
Re: [Pharo-users] type checking in Smalltalk
In other words: don't ask - tell. Instead of writing something like: object isSomething ifTrue: [ object doSomething ] ifFalse: [ object doSomethingElse ] just write it: object doSomething that gives you much less code bloat, and much clear view of your intent(s) and even in case of exception , you can always interpret DNU as "object are missing feature, you asked for", which is again, reveals your intent. Also things like: object isSomething ifTrue: [ self doSomethingWith: object ] ifFalse: [ self doSomethingElseWith: object ] in general considered as anti-pattern, because you basically implementing polymorphic behavior in wrong place i.e. in code that using object, instead of code that belongs to the object itself. On 31 March 2017 at 03:05, Ben Coman <b...@openinworld.com> wrote: > > > On Thu, Mar 30, 2017 at 11:06 PM, Stephan Eggermont <step...@stack.nl> > wrote: > > On 30/03/17 16:03, Marc Hanisch via Pharo-users wrote: > >> > >> Reading this, I realized, that I never saw such type-checking in > >> Pharo production code. So the question is, what are recommended > >> design principles for that problem in Smalltalk? Do you use what is > >> called duck typing? > > > > > > Normally I'm not interested in what an object is, but what it can do. > > So a test on #respondsTo: can tell me if the object knows how to do > > something. > > > > In smalltalk, I can add methods to existing classes, so there are a lot > of > > extension methods on Object isXYZ, returning false. Morph returns true to > > isMorph, so all subclasses of Morph can be recognized that way. > > Many people also technically frown on isXYZ is a similar way to isKindOf:, > but it is a lesser evil and pragmatically is used reasonably often. > > > > > Instead of adding a test method, there are also empty implementations > > Like this, what you can do is refactor that guarded code into a method > #myAction > and add Object>>myAction which throws the exception. > Thus you condense multiple condition statements into > one location and your application code becomes much cleaner. > > Object may end up loaded with a lot of methods not of interest to every > object, > but the trade-off of cleaner application code is generally worth it. > > btw, Here you start to see how using Pharo/Smalltalk "changes the way you > think about programming". > > Further, the exception thrown by Object>>myAction > should signal the error on a custom error object, similar to ZeroDivide > for example. > > > > or ones that return self or an appropriate null-value. > > Within your framework where you control all the objects > the Null-object pattern is probably the cleanest OO approach, > but it can't control what the user passes across the public API. > https://en.wikipedia.org/wiki/Null_Object_pattern > > btw, you can search null-object pattern in Spotter using " Null #c " > > > cheers -ben > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] What is the craziest bug you ever face
I don't think my reply will be anything useful, but as to me the most craziest bug is metabug, i.e. when system doesn't provides any means to debug things. :) As for regular bugs .. it is quite hard to remember anything i wasn't able to deal with, given enough time & effort, and then emphasize single case over the rest. And since human brains tend to forget unpleasant things, there's not much details to tell and remember. On 9 March 2017 at 13:36, Stephane Ducasse <stepharo.s...@gmail.com> wrote: > Hi guys > > During the DSU workshop we were brainstorming about what are the most > difficult bugs we faced and what are the conceptual tools that would have > helped you. > > Stef > -- Best regards, Igor Stasenko.
Re: [Pharo-users] why is concat of Symbols a string?
On 6 March 2017 at 15:21, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>
> > On 6 Mar 2017, at 14:12, Ben Coman <b...@openinworld.com> wrote:
> >
> >
> >
> > On Mon, Mar 6, 2017 at 5:54 PM, Sven Van Caekenberghe <s...@stfx.eu>
> wrote:
> > Here is a concrete proposal:
> >
> > https://pharo.fogbugz.com/f/cases/19802/Make-sure-Symbol-
> concatenation-results-in-a-Symbol-not-a-String
> >
> > This gives the following assertions:
> >
> > "Concatenating 2 symbols results in abother symbol"
> > self assert: (#foo , #bar) == #foobar.
> >
> > "Concatenating the empty symbol does not change a symbol"
> > self assert: (#foo, emptySymbol) == #foo.
> > self assert: (emptySymbol, #foo) == #foo.
> >
> > "Strings and symbols can still be mixed, the receiver determines
> the result type"
> > "Symbol receiver gives symbol result"
> > self assert: (#foo , 'bar') == #foobar.
> > "String receiver gives string result"
> > self deny: ('foo' , #bar) == #foobar.
> > self assert: ('foo' , #bar) equals: #foobar.
> > self assert: ('foo' , #bar) equals: 'foobar'.
> >
> >
> > Those last two seem contradictory.
>
> No, Symbols and String can be used interchangeably in Pharo in lots of
> contexts. Particularly when comparing them, it makes no difference, all the
> following are/have always been true, independent of this change:
>
> #foo = 'foo'
> 'foo' = #foo
> #foo = #foo
> 'foo' = 'foo'
>
> But maybe it is a bit confusing with an extra comment.
>
> You got me with this...
Hey, stop confusing people, put #== everywhere! :)
But if seriously, #assert:equals: hides this detail from us, that's why it
looks confusing..
IMO, for given case it would be better to use just straight #assert:, with
explicit expression that using #= for comparands.
--
Best regards,
Igor Stasenko.
Re: [Pharo-users] Crash in Athens
On 5 March 2017 at 11:03, Esteban Lorenzano <esteba...@gmail.com> wrote: > > On 5 Mar 2017, at 05:00, Alexander Samoylovich <samoylov...@gmail.com> > wrote: > > Hi Ronie, Esteban. > > Ronie's suggestion in the form Esteban presented it helped. > After implementing the fix I failed to crash my application any more. > > Will anybody be so kind to explain me what actually happens and why the > fix works? > It looks so innocent. > > > Cairo Surface is GCd if not kept while using it… then your system go BOOM > :P > that’s why we need to be sure it will not be disposed before it’s time > (hence we kept it in the form that needs to be displayed). > > Well, this surely helps when you changing session(s). But doesn't helps when you crashing within a single session. A smarter approach will be to recreate surface at attempt to use in new session, to avoid keeping copy of data around.. > Esteban > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] why is concat of Symbols a string?
Hmm.. symbols is usually treated like immutable object(s) in system. They tend to stay while rest of data changes.. This could explain why authors of this method purposedly picked to use ByteString for its species to discourage using symbols for collection manipulation(s).. Else, if you would need to change this method as well: at: anInteger put: anObject "You cannot modify the receiver." self errorNoModification because base class #, implementation is going to use at:put: during concatenation. On 4 March 2017 at 13:40, Clément Bera <bera.clem...@gmail.com> wrote: > Hi, > > All symbols are interned in the Symbol table. If one does (#foo , #bar , > #baz) and each returned value would be a symbol, then both #foobar and > #foobarbaz would be registered in the symbol table. > > I would guess that's why the concatenated value is a string and not a > symbol, to avoid registering many unused symbols. But maybe I am wrong. > > If for your use case you need to concatenate symbols and get a symbol out > of it, you can define a new method in Symbol to do what you want. > > For example: > > Symbol >> ,, arg > ^ (self , arg) asSymbol > > Then > > #foo ,, #bar > > Answers directly the symbol #foobar. > > Best, > > > > > On Sat, Mar 4, 2017 at 11:36 AM, Peter Uhnak <i.uh...@gmail.com> wrote: > >> Hi, >> >> why is the concatenation of symbols a string? >> >> e.g. #desc, #Name -> 'descName' >> >> this means that I have to always wrap in parentheses and recast, or >> stream it, e.g. >> >> (#desc, #Name) asSymbol -> #descName >> Symbol streamContents: [ :s | s << #desc; << #Name ] -> #descName >> >> both of which introduce extraneous syntactical clutter. >> The technical reason seems to be ByteSymbol>>#species returning >> ByteString, but I have no idea why it has to be this complicated. >> >> Thanks, >> Peter >> >> > -- Best regards, Igor Stasenko.
Re: [Pharo-users] Crash in Athens
On 1 March 2017 at 05:42, Alexander Samoylovich <samoylov...@gmail.com> wrote: > Thanks everybody for the explanation. > > I tried to apply Igor's suggestion. I allocate an offscreen surface 1 row > larger than needed > and when converting discard one row. > > The code looks more stable now. The test was up for about 30 minutes > before crashing instead of 1 minute before the fix. > Is it the right code change or just a coincidence? > > > AthensCairoSurface>>asForm > > > "create a form and copy an image data there" > > self checkSession. > > self flush. > > ^ Form extent: (self width@self height) - (0@1) depth: 32 bits: id > > no, it isn't . This is how it supposed to be there. But the problem is when you using surfaces for bitmaps in Cairo itself, you're screwed since AthensCairoSurface purposedly makes it 1 row taller, while for texture you want it to contain exact height, else you'll obviously have artifacts. :( So, the point is: if you creating a surface that will be used by bitblt (asForm), then you should allocate 1 extra row, else you shouldn't.. And there's no workaround to match such behavior in single class, since it doesn't knows what it will be used for :( > > On Mon, Feb 27, 2017 at 2:39 PM, Stephane Ducasse <stepharo.s...@gmail.com > > wrote: > >> Tx igor I added >> >> https://pharo.fogbugz.com/f/cases/19764/Improve-comment-of- >> AthensCairoSurfaceForm >> >> On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <siguc...@gmail.com> >> wrote: >> >>> and i was dealing with it by adding 1 extra line to cairo surface, >>> but reporting 1 less to Form. Like so, bitblt still reads past the >>> allowed size, but it is safe, because there are unused bit(s). >>> >>> On 27 February 2017 at 20:31, Igor Stasenko <siguc...@gmail.com> wrote: >>> >>>> >>>> >>>> On 27 February 2017 at 12:29, Esteban Lorenzano <esteba...@gmail.com> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> the problem wit Ronie’s fix is that (as he says) you are copying >>>>> another time the surface, before passing it to the VM (who makes >>>>> yet-another-copy) so this is not optimal… and you can see it when running >>>>> the Tiger demo: there are a lot of pauses. >>>>> So I would prefer the other approach he suggests: >>>>> >>>>> Form subclass: #AthensCairoSurfaceForm >>>>> instanceVariableNames: 'surface' >>>>> classVariableNames: '' >>>>> package: 'Athens-Cairo' >>>>> >>>>> AthensCairoSurfaceForm>>surface >>>>> ^ surface >>>>> >>>>> AthensCairoSurfaceForm>>surface: anObject >>>>> surface := anObject >>>>> >>>>> AthensCairoSurface>>asForm >>>>> "create a form and copy an image data there" >>>>> self checkSession. >>>>> self flush. >>>>> ^ (AthensCairoSurfaceForm extent: (self width@self height) >>>>> depth: 32 bits: id) >>>>> surface: self; >>>>> yourself >>>>> >>>>> that seems to work. Can you try and see? >>>>> >>>>> >>>> Btw, remember the culprit there , that you must have extra word in >>>> trailing buffer space, >>>> this is because bit-blt using read-ahead . Which is OK for objects >>>> located in object memory, >>>> since there are always something past the last object (unallocated >>>> space), >>>> but not so ok for buffers allocated by malloc (such as cairo surface >>>> bitmap), and so, >>>> if you read even a single byte past it, you get protection fault. >>>> >>>> >>>>> Esteban >>>>> >>>>> > On 24 Feb 2017, at 15:47, stepharong <stephar...@free.fr> wrote: >>>>> > >>>>> > Hi alex >>>>> > >>>>> > can you try the fix of ronie and let us know if it makes roassal >>>>> more stable? >>>>> > >>>>> > Stef >>>>> > >>>>> >> Dear Alexander, >>>>> >> >>>>> >> Sine the new FFI of Pharo, using Athens has become unreliable. This >>>>> is a pity, but fixing this is not trivial at all (we have been trying for >>>>> years). >>>>> >> >>>>> >> What exactly are you doing with Athens? >>>>> >> >>>>> >> Alexandre >>>>> >> >>>>> >> >>>>> >>> On Feb 22, 2017, at 12:55 AM, Alexander Samoylovich < >>>>> samoylov...@gmail.com> wrote: >>>>> >>> >>>>> >>> Hello >>>>> >>> >>>>> >>> I am writing graphic demo programs using Athens on Mac Sierra. >>>>> >>> Time by time Pharo VM crashes. Programs not using Athens work >>>>> reliably. >>>>> >>> I believe the behavior is reproducible. >>>>> >>> How should I report a bug? >>>>> >>> >>>>> >>> Alex >>>>> >> >>>>> > >>>>> > >>>>> > -- >>>>> > Using Opera's mail client: http://www.opera.com/mail/ >>>>> > >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > -- Best regards, Igor Stasenko.
Re: [Pharo-users] Crash in Athens
and i was dealing with it by adding 1 extra line to cairo surface, but reporting 1 less to Form. Like so, bitblt still reads past the allowed size, but it is safe, because there are unused bit(s). On 27 February 2017 at 20:31, Igor Stasenko <siguc...@gmail.com> wrote: > > > On 27 February 2017 at 12:29, Esteban Lorenzano <esteba...@gmail.com> > wrote: > >> Hi, >> >> the problem wit Ronie’s fix is that (as he says) you are copying another >> time the surface, before passing it to the VM (who makes yet-another-copy) >> so this is not optimal… and you can see it when running the Tiger demo: >> there are a lot of pauses. >> So I would prefer the other approach he suggests: >> >> Form subclass: #AthensCairoSurfaceForm >> instanceVariableNames: 'surface' >> classVariableNames: '' >> package: 'Athens-Cairo' >> >> AthensCairoSurfaceForm>>surface >> ^ surface >> >> AthensCairoSurfaceForm>>surface: anObject >> surface := anObject >> >> AthensCairoSurface>>asForm >> "create a form and copy an image data there" >> self checkSession. >> self flush. >> ^ (AthensCairoSurfaceForm extent: (self width@self height) >> depth: 32 bits: id) >> surface: self; >> yourself >> >> that seems to work. Can you try and see? >> >> > Btw, remember the culprit there , that you must have extra word in > trailing buffer space, > this is because bit-blt using read-ahead . Which is OK for objects located > in object memory, > since there are always something past the last object (unallocated space), > but not so ok for buffers allocated by malloc (such as cairo surface > bitmap), and so, > if you read even a single byte past it, you get protection fault. > > >> Esteban >> >> > On 24 Feb 2017, at 15:47, stepharong <stephar...@free.fr> wrote: >> > >> > Hi alex >> > >> > can you try the fix of ronie and let us know if it makes roassal more >> stable? >> > >> > Stef >> > >> >> Dear Alexander, >> >> >> >> Sine the new FFI of Pharo, using Athens has become unreliable. This is >> a pity, but fixing this is not trivial at all (we have been trying for >> years). >> >> >> >> What exactly are you doing with Athens? >> >> >> >> Alexandre >> >> >> >> >> >>> On Feb 22, 2017, at 12:55 AM, Alexander Samoylovich < >> samoylov...@gmail.com> wrote: >> >>> >> >>> Hello >> >>> >> >>> I am writing graphic demo programs using Athens on Mac Sierra. >> >>> Time by time Pharo VM crashes. Programs not using Athens work >> reliably. >> >>> I believe the behavior is reproducible. >> >>> How should I report a bug? >> >>> >> >>> Alex >> >> >> > >> > >> > -- >> > Using Opera's mail client: http://www.opera.com/mail/ >> > >> >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
Re: [Pharo-users] Crash in Athens
On 27 February 2017 at 12:29, Esteban Lorenzano <esteba...@gmail.com> wrote: > Hi, > > the problem wit Ronie’s fix is that (as he says) you are copying another > time the surface, before passing it to the VM (who makes yet-another-copy) > so this is not optimal… and you can see it when running the Tiger demo: > there are a lot of pauses. > So I would prefer the other approach he suggests: > > Form subclass: #AthensCairoSurfaceForm > instanceVariableNames: 'surface' > classVariableNames: '' > package: 'Athens-Cairo' > > AthensCairoSurfaceForm>>surface > ^ surface > > AthensCairoSurfaceForm>>surface: anObject > surface := anObject > > AthensCairoSurface>>asForm > "create a form and copy an image data there" > self checkSession. > self flush. > ^ (AthensCairoSurfaceForm extent: (self width@self height) depth: > 32 bits: id) > surface: self; > yourself > > that seems to work. Can you try and see? > > Btw, remember the culprit there , that you must have extra word in trailing buffer space, this is because bit-blt using read-ahead . Which is OK for objects located in object memory, since there are always something past the last object (unallocated space), but not so ok for buffers allocated by malloc (such as cairo surface bitmap), and so, if you read even a single byte past it, you get protection fault. > Esteban > > > On 24 Feb 2017, at 15:47, stepharong <stephar...@free.fr> wrote: > > > > Hi alex > > > > can you try the fix of ronie and let us know if it makes roassal more > stable? > > > > Stef > > > >> Dear Alexander, > >> > >> Sine the new FFI of Pharo, using Athens has become unreliable. This is > a pity, but fixing this is not trivial at all (we have been trying for > years). > >> > >> What exactly are you doing with Athens? > >> > >> Alexandre > >> > >> > >>> On Feb 22, 2017, at 12:55 AM, Alexander Samoylovich < > samoylov...@gmail.com> wrote: > >>> > >>> Hello > >>> > >>> I am writing graphic demo programs using Athens on Mac Sierra. > >>> Time by time Pharo VM crashes. Programs not using Athens work reliably. > >>> I believe the behavior is reproducible. > >>> How should I report a bug? > >>> > >>> Alex > >> > > > > > > -- > > Using Opera's mail client: http://www.opera.com/mail/ > > > > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] About asSymbol message , some questions in my mind
On 13 February 2017 at 13:48, lb <liangbin...@126.com> wrote: > Just To You, :-) > Symbol , a sign with some meaning in nature language. > eg, #% = percent, #$ = dollar. > but > 2. '$%%&' asSymbol >>>>no meaning > > symbol as a message should have his meaning. defined in its method. > a message should let programmer know what to do. > > I come from China , My English is poor. > Hmm.. Then why it is so hard for you to comprehend such simple concept? In Chinese you have thousands unique glyphs, that you can use for writing, and each one has own meaning. Sometimes they literally mean something, but sometimes the meaning depends on context. That means that symbols '@#&%@#$' may not have meaning for most uses, while for some other can. This depends on context. Now if you take into account that in English, there's not so many glyphs for letter, so you have to use combination(s) of them to form words, phrases etc.. that could have meaning in specific context, while not have in other. > > Cheers. > > Bing > > 在 2017-02-13 07:26:05，"john pfersich" <jpfers...@gmail.com> 写道： > > BUT There are not compliant below > 1.' ' asSymbol >>>>no meaning > 2. '$%%&' asSymbol >>>>no meaning > 3. 'sign' asSymbol = 'sign ' asSymbol >>> false because of space. > 3. ' one two three ' asSymbol >>>I think It should > become three symbols = #one, #two, #three > > I don't know what you mean by "no meaning', they're symbols. > Try this in a Playground, it works in Pharo 5" > > | oc sym filtered| > oc := ' one two three $%%&' splitOn: ' '. > sym := OrderedCollection new. > oc do: [:each | sym add: each asSymbol]. > filtered := OrderedCollection new. > filtered := sym select: [ :each | each ~= #'' ]. > Transcript show: sym printString; cr. > Transcript show: filtered printString; cr. > > On Fri, Feb 10, 2017 at 8:56 PM, lb <liangbin...@126.com> wrote: > >> Hi, >> I know Symbol is subclass of String. >> Any string object can become symbol object by sending 'asSymbol' message.. >> I think symbol must has its meaning in comon use, so the symbol should >> be composed of alphabet or number ‘without space“. >> >> BUT There are not compliant below >> 1.' ' asSymbol >>>>no meaning >> 2. '$%%&' asSymbol >>>> no meaning >> 3. 'sign' asSymbol = 'sign ' asSymbol >>> false because of space. >> 3. ' one two three ' asSymbol >>>I think It should >> become three symbols = #one, #two, #three >> >> >> Mybe my understanding is wrong. >> >> Bing Liang >> >> >> > -- Best regards, Igor Stasenko.
Re: [Pharo-users] [ANN] CPPBridge: One Ring to rule them ALL
On 10 November 2016 at 11:36, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > > >> Well, a while before that, i wrote own lobotomized smalltalk >> implementation in C and started generating bindings to Ogre3D engine. I >> even had certain success with it, but then i started grand-rewriting of VM >> and abandoned it. >> That was before i switched to Squeak, then Pharo. So, your incentives >> quite familiar to me :) >> I was quite fun journey, and i learned a lot while doing it.. especially >> about smalltalk. >> >> > I have no interest into implementing Smalltalk at C side , neither my > purpose is education, quite the contrary I try to find way to utilize Pharo > the best way possible without compromising on performance > > >> I don't understand why people find assembly scary or mind-boggling? I >> dived into assembly few months after i learned my first programming >> language, it was Zilog 8-bit CPU. A marvelous gem :) >> And this was always fascinating to feel that you can control the >> computer's behaviour down to a tiniest detail. We were even researching >> what certain i/o ports and interrupts were responsible for by setting >> different bits/bytes here and there and see what happen. >> Because if you don't understand something down to the tiniest detail - >> you cannot be sure that what you doing will work, or work optimally. >> So i find it frustrating that most of programmers don't know and not even >> thinking about touching assembly. Because it very simple, straightforward >> and megalomaniac-rewarding :) >> -- >> Best regards, >> Igor Stasenko. >> > > Assembly is hard, just compare its hello world with the hello world of > other progamming languages. Its just insane. > you are looking at wrong angle. To print 'hello world' in most of languages is a matter of single and simple expression. Which usually considered an elementary operation in this language. It just happens that in assembler the elementary operation is different, but it doesn't means that you cannot look at a single expression (any instruction) and cannot understand what it does.. e.g. - it prints 'hello world' or - it sets the register value both quite simple, elementary and easy to understand, isn't? Just different levels of abstraction. > > The thing is that because we started on early , we experienced assembly > when it used to be fairly simple. I started with an Amstrad CPC 6128 with > 128 kb of ram and 4 mhz CPU, it uses Z80 assembly which is fairly simple > even when compared to Pharo. > > Modern Assembly however have grown on complexity because it depend on the > complexity of the hardware. Personally I don even like to call it a > programming language , just beautified machine code. > i was never considered assemble as a language, it is indeed just a set of CPU instructions. the early assembler compilers is a thin wrappers with slight syntactic sugar here and there.. but not much different to direct instructions. so i would not call it programming language.. since it usually abstracts nothing from direct machine code. > > I agree though Assembly is a lot of fun and a great source of knowledge. > -- Best regards, Igor Stasenko.
Re: [Pharo-users] about balkanisation
On 10 November 2016 at 06:07, Dale Henrichs < dale.henri...@gemtalksystems.com> wrote: > > > On 11/8/16 11:04 PM, Igor Stasenko wrote: > > > > On 7 November 2016 at 14:28, stepharo <steph...@free.fr> wrote: > >> >> [ ... ] >> >> >> And this one I don't understand. A smooth, git / iceberg oriented >> transition over Monticello/Metacello is perfectly doable... As Dale >> explained. A nice Iceberg gui reworking / making git usable is perfect. >> >> But why make the transition so hard? You get Stef angry on a Sunday >> morning because he can't find things anymore... even if he is a strong >> proponent of the strategy he complains about ;) >> >> >> No my point was not that. >> My point is that it is important to pay attention and not to add more >> noise than necessary. Let us take the time and move alltogether. >> >> If you want to get somewhere with this story, you don't want to wait till > everything will be ready. > Transition will never start unless you force users to enter the minefield > and let them clear the mines for you. Step by step. Many will blow > themselves up, while some will manage to pass unhurt.. > Because else, it will be always a minefield between you and the > destination of your journey :) > > I think that at the early stages of the transition you have to support > both approaches ... when the new tools are in place and stabilized then one > can consider ... the transition has already started so this is not a case > where you need to force folks to change, but a case where you need to > support the folks who choose to change ... it can be relatively low cost to > keep the old tools around for quite awhile ... I would think ... > > Right, as i said: make a minefield and watch those who wanting to cross it. And big mistake then to shout: hey i will never ever step on it.. This is bad idea, since you discouraging people from doing what you need :) > Dale > -- Best regards, Igor Stasenko.
Re: [Pharo-users] [ANN] CPPBridge: One Ring to rule them ALL
On 9 November 2016 at 08:41, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > I am the only potential customer of CPPBridge because > > a) I am the only C++ coder AFAIK > b) Using DLLs (dynamically linked shared libraries) is still by far the > best solution because using the UFFI you can do everything from Pharo. > Compared to CPPBridge which you will need to code in C++. > > So as you can imagine making a general library for IPC communication via > shared memory is not my goal. > > The Unreal part will be a separate library that will depend on this one. I > have not touched that one yet but I will soon. > > UnrealBridge library will become my most important Pharo project because > the goal is to start selling games using Pharo and Unreal. > > IPC Protocol wise , I don't think synchronisation will be an issue because > Unreal will be too fast for Pharo anyway and its ok if Pharo lags behind > even a few dozens of milliseconds which is a matter of losing a couple of > frames. I may implement a hybrid synchronisation for when Pharo lag becomes > too severe but that will have and see in practice. > > Something that interest me is "stealing" your idea for NBOpenGL where you > made an automatic generator for the library that used OpenGL headers. This > is something that could benefit me a lot because Unreal contains over > 10.000 methods and wrapping them one by one is not something I am looking > forward to doing. This means generating both C++ and Pharo code. > > Well, a while before that, i wrote own lobotomized smalltalk implementation in C and started generating bindings to Ogre3D engine. I even had certain success with it, but then i started grand-rewriting of VM and abandoned it. That was before i switched to Squeak, then Pharo. So, your incentives quite familiar to me :) I was quite fun journey, and i learned a lot while doing it.. especially about smalltalk. Of course if I feel that what I implement with UnrealBridge is general > purpose enough I can port it back to CPPBridge. > > In any case I must say it was a lot of fun accomplishing this goal and > cant wait to dive deeper into IPC magic, making Pharo the nerve centre, the > brain , of my coding environment is a role that I think Pharo would excel > at. It will also allow me to use Pharo as much as possible and provide a > super powerful game / graphics engine to the Pharo community. Shared memory > is that just the means to that goal. > > Moose could also a play role later on for analysing my game code both in > Pharo and C++ and use Roassal for some nifty visualizations though I could > use Unreal as backend to Roassal for some nice 3d visualisations. > > So ton of ideas, tons of fun and a ton of time to accomplish them. > > PS: I have to say you have been inspiration for my IPC saga, you did the > unthinkable (at least to me) and brought Assembly to Pharo, I never had a > use for Assembly but nonetheless you taught me that Pharo potential is more > massive than I imagined, so thank you :) > I don't understand why people find assembly scary or mind-boggling? I dived into assembly few months after i learned my first programming language, it was Zilog 8-bit CPU. A marvelous gem :) And this was always fascinating to feel that you can control the computer's behaviour down to a tiniest detail. We were even researching what certain i/o ports and interrupts were responsible for by setting different bits/bytes here and there and see what happen. Because if you don't understand something down to the tiniest detail - you cannot be sure that what you doing will work, or work optimally. So i find it frustrating that most of programmers don't know and not even thinking about touching assembly. Because it very simple, straightforward and megalomaniac-rewarding :) -- Best regards, Igor Stasenko.
Re: [Pharo-users] Converting an Array of Characters to a String
On 9 November 2016 at 07:49, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > Not in C but there std::string in C++ similar to our String object. > > Strictly speaking , std::string is again not part of C++ per se, it comes from library that implements such class. > C char indeed is more a byte array than a string. Actually C won't allow > to change the string value mainly because it thinks you try to change the > size which something that is not allowed for arrays anyway, so the only way > to change a char string aka char array is character by character. > > Null termination is why I filled the shared memory with zeros to be on the > safe side and then added the string and the number on top > > just wanted to warn you, to make sure you understand that char[100] is not string, not in C , not in C++. And, of course, it should not autoconvert to smalltalk String object(s) in FFI, because many C coders use 'char' as a default data type to operate with buffers of certain length and to count their size in bytes. > On Wed, 9 Nov 2016 at 03:41, Igor Stasenko <siguc...@gmail.com> wrote: > >> What i meant, i wanted to warn Dimitris that >> char[100] >> are just array of 100 characters (bytes in C).. and has nothing to do >> with strings. >> Do not confuse fixed-length C arrays with strings. There's no 'string' >> data type in C, and instead they use null-terminated character sequence as >> a convention. But it is not a fixed-size data. >> >> On 9 November 2016 at 02:38, Igor Stasenko <siguc...@gmail.com> wrote: >> >> >> >> On 8 November 2016 at 14:42, Esteban Lorenzano <esteba...@gmail.com> >> wrote: >> >> (always with Char100 example in mind): >> >> s := MyStructure fromHandle: blah. >> string := s data readString. >> >> should work. >> >> >> IIRC, #readString works correctly only for correctly null-terminated >> strings. If not, it will read beyond the structure size , until it find a >> zero byte somewhere in memory, >> and thus, results may vary :) >> >> >> Esteban >> >> >> > On 8 Nov 2016, at 14:31, Dimitris Chloupis <kilon.al...@gmail.com> >> wrote: >> > >> > I feel like stupid but I cannot find a way to convert an Array of >> Characters to a String , I can do with a do: and join characters converted >> to strings to a single string but it feels too many steps. >> > >> > Is there a simpler way ? >> >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.
Re: [Pharo-users] about balkanisation
On 7 November 2016 at 14:28, stepharo <steph...@free.fr> wrote: > > [ ... ] > > > And this one I don't understand. A smooth, git / iceberg oriented > transition over Monticello/Metacello is perfectly doable... As Dale > explained. A nice Iceberg gui reworking / making git usable is perfect. > > But why make the transition so hard? You get Stef angry on a Sunday > morning because he can't find things anymore... even if he is a strong > proponent of the strategy he complains about ;) > > > No my point was not that. > My point is that it is important to pay attention and not to add more > noise than necessary. Let us take the time and move alltogether. > > If you want to get somewhere with this story, you don't want to wait till everything will be ready. Transition will never start unless you force users to enter the minefield and let them clear the mines for you. Step by step. Many will blow themselves up, while some will manage to pass unhurt.. Because else, it will be always a minefield between you and the destination of your journey :) > Stef > > > Thierry > > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] Converting an Array of Characters to a String
What i meant, i wanted to warn Dimitris that char[100] are just array of 100 characters (bytes in C).. and has nothing to do with strings. Do not confuse fixed-length C arrays with strings. There's no 'string' data type in C, and instead they use null-terminated character sequence as a convention. But it is not a fixed-size data. On 9 November 2016 at 02:38, Igor Stasenko <siguc...@gmail.com> wrote: > > > On 8 November 2016 at 14:42, Esteban Lorenzano <esteba...@gmail.com> > wrote: > >> (always with Char100 example in mind): >> >> s := MyStructure fromHandle: blah. >> string := s data readString. >> >> should work. >> >> > IIRC, #readString works correctly only for correctly null-terminated > strings. If not, it will read beyond the structure size , until it find a > zero byte somewhere in memory, > and thus, results may vary :) > > >> Esteban >> >> >> > On 8 Nov 2016, at 14:31, Dimitris Chloupis <kilon.al...@gmail.com> >> wrote: >> > >> > I feel like stupid but I cannot find a way to convert an Array of >> Characters to a String , I can do with a do: and join characters converted >> to strings to a single string but it feels too many steps. >> > >> > Is there a simpler way ? >> >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
Re: [Pharo-users] Converting an Array of Characters to a String
On 8 November 2016 at 14:42, Esteban Lorenzano <esteba...@gmail.com> wrote: > (always with Char100 example in mind): > > s := MyStructure fromHandle: blah. > string := s data readString. > > should work. > > IIRC, #readString works correctly only for correctly null-terminated strings. If not, it will read beyond the structure size , until it find a zero byte somewhere in memory, and thus, results may vary :) > Esteban > > > > On 8 Nov 2016, at 14:31, Dimitris Chloupis <kilon.al...@gmail.com> > wrote: > > > > I feel like stupid but I cannot find a way to convert an Array of > Characters to a String , I can do with a do: and join characters converted > to strings to a single string but it feels too many steps. > > > > Is there a simpler way ? > > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] UFFI can not generate Structure accessor of type char[100]
On 8 November 2016 at 13:11, Esteban Lorenzano <esteba...@gmail.com> wrote: > > On 8 Nov 2016, at 12:55, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > > Thank you Esteban > > By the way I really love the design of UFFI , very clean and quite easy to > understand , great work to you and Igor :) > > > UFFI is just mine ;) > (but I sanded in giant shoulders as I took Igor work as inspiration… and > to “borrow” many cool ideas) > > Your credit is too generous :) Btw, is this expression: FFITypeArray ofType: #char. creates anonymous class, or you making an instance of something? Because if it anonymous class, i was always warned against use it in such form, and instead use some kind of class initializers to generate all the 'types' you will use in future i.e. MyCalss class>>initialize MyCharr100Type := FFITypeArray ofType: #char size:100. and then just use it wherever you need i.e.: mychars := MyChar100Type new. .. whatever. > Esteban > > > On Tue, Nov 8, 2016 at 1:54 PM Esteban Lorenzano <esteba...@gmail.com> > wrote: > >> On 8 Nov 2016, at 12:49, Dimitris Chloupis <kilon.al...@gmail.com> wrote: >> >> I was reaching a similar conclusion >> >> Currently I have a void pointer to the struct with the members I >> mentioned >> >> I can get char[100] >> >> pointerToStruct fromCString >> >> and I can get the int with >> >> pointerToStruct getHandle integerAt: 101 size:4 signed: false >> >> so if I want to pass the address of the pointer to my YourStruct instance >> will I have to initialize with >> >> YourStruct fromHandler: (pointerToStruct getHandle) >> >> is this a correct and safe way to pass the address ? >> >> >> yes. >> >> Esteban >> >> >> >> On Tue, Nov 8, 2016 at 1:21 PM Esteban Lorenzano <esteba...@gmail.com> >> wrote: >> >> it never could. >> you need to do a “special type”, who has to be something like: >> >> YourStruct class>>initialize >> Char100 := FFITypeArray ofType: #char. >> >> fieldsDesc >> ^ #( >> Char100 data; >> int count; >> ) >> >> but then… you want to optimise that and in field accessors, who will look >> something like this: >> >> YourStruct >>data >> "This method was automatically generated" >> ^(FFITypeArray ofType: #char size: 100) fromHandle: (handle >> copyFrom: 1 to: 100) >> >> you can change that for: >> >> YourStruct >>data >> "This method was automatically generated" >> ^Char100 fromHandle: (handle copyFrom: 1 to: 100) >> >> and same for setter. >> (other way will work, but it will be suboptimal) >> >> Esteban >> >> > On 8 Nov 2016, at 12:10, Dimitris Chloupis <kilon.al...@gmail.com> >> wrote: >> > >> > I have FFIExternalStructure which has at class side >> > >> > fieldsDesc >> > ^#( >> > char data[100]; >> > int count; >> > ) >> > >> > if I try to do >> > >> > EphCPPTestStructure rebuildFieldAccessors . >> > >> > in order to generate the accessors for the members of the struct it >> complains with an error that it does not recognise the type of " [ " >> > >> > Does that mean that char arrays are other arrays are not supported as >> struct members or will I have to do this manually ? >> >> >> > -- Best regards, Igor Stasenko.
Re: [Pharo-users] [ANN] CPPBridge: One Ring to rule them ALL
On 9 November 2016 at 02:09, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > I have only played with c structs and it looks like they do the job fine . > If json parsing is slow especially in Pharo then it's out of the question. > Parsing must be kept close to zero because I will be running some very > tight loops of 100 frames per second and there is no way that I will let > Pharo take its time as the whole idea of using the fastest way to IPC was > to keep Pharo in sync with unreal . Heavy lifting will be done only by > Unreal. Pharo will be used just for logic. > > Well, it depends what you want: if you want to give away a complete/general solution for IPC with Pharo via shared memory, then you should create some kind of library (both C++ and Pharo) which would allow users to setup the bridge configuration in the way they want, leaving the application-specific exchange to the hands of users.. And if you just want to make own data exchange for own purpose, then you are basically done. > In any case there is a ton of testing and profiling needed to be done . So > these are just the first steps. > On Wed, 9 Nov 2016 at 02:58, Igor Stasenko <siguc...@gmail.com> wrote: > >> JSON? -- But you were talking about speed. Once you put JSON as a base >> for IPC, then say goodbye to speed. >> >> Because JSON parsing/writing will eat like 90% of time even if you would >> use sockets. >> So, why not using some kind of binary protocol? >> Unless you wanna use JSON for initial handshaking exchange. Then it is >> quite reasonable. >> >> But all of that still won't free you from inventing some kind of >> contract(s) which would allow parties to agree who writes where and/or who >> writes, while other waits then reads etc. >> >> >> On 9 November 2016 at 00:06, Dimitris Chloupis <kilon.al...@gmail.com> >> wrote: >> >> >> *https://youtu.be/pI4PR3XaX6Q <https://youtu.be/pI4PR3XaX6Q>* >> >> *What is it ?* >> >> CPPBridge is a library that allows Pharo to share memory with any C/C++ >> application. Opening the door not only to IPC and data sharing but also >> even complete control of C++ code from Pharo and vice versa. >> >> *How to install ?* >> >> In a few hours it should be available from Package Browser, if not you >> can always fetch it with Metacello from here because it comes with a >> Baseline >> >> https://github.com/kilon/CPPBridge >> >> *Why bother making such a library ? * >> >> In my saga to find a way to use Pharo as a scripting language for Unreal >> Game Engine, I had two options >> >> a) Build Unreal as a Library and use Pharo UFFI to launch and control it >> b) Embed Pharo inside the Unreal Executable (this is what every other >> scripting language uses for controlling Unreal) >> >> Option (a) was a no go, because Unreal is huge , complex and uses its own >> custom made build tools, making a DLL for Pharo or an army of DLLs out of >> the question >> >> Option (b) Embeding Pharo inside an executable is impossible and >> implementing it also insanely complex >> >> Naturally my mind went first into sockets which is what I use to make >> Pharo able to use Python libraries. However sockets have proven too slow >> for the insanely fast loops of Unreal. >> >> *What are the advantages ?* >> >> 1) *No need to move data around.* Sharing memory means you don't have to >> move data around, you can use directly the shared memory >> >> 2)* Extend the Pharo image beyond Pharo.* Shared memory is mapped into a >> file means that you can do with C++ what you can do with Pharo image, save >> the live state directly to a binary file. That means we no longer need to >> worry about sessions and reinitializing C/C++ data since memory mapped file >> acts as an extension of the Pharo image. >> >> 3) *Blazing fast. *Memory mapping is a function that comes directly from >> the OS kernel and as such it has to be extremely fast. Memory mapping is >> also what is used for dynamically linked shared libraries an extremely >> important feature for any application including Pharo that heavily depends >> on (see Cairo for Athens). So its a very mature , well tested method. >> >> 4) *No extra libraries needed* to be installed, CPPBridge uses OS >> libraries to work out of the box >> >> 5) *Low level handling of memory.* Direct access to memory you can even >> manipulate the memory byte by byte >> >> 6)* Memory efficient.* Memory mapping excels at large data, the bigger >> the better. Can take full advantage o
Re: [Pharo-users] [ANN] CPPBridge: One Ring to rule them ALL
ocket > bridge to Python > > 4) *UFFI still No1 option*. No replacement for UFFI it actually depends > on it to work , so if you can turn your C/C++ code into a DLL that should > be your first option. > > *Roadmap * > > Currently CPPBridge works only on MacOS , most likely on Linux too > (because it uses the Unix architecture) but I will have to test it. > > Windows is coming next ASAP, since its my No1 platform for creating > commercial games. > > Maybe establish a small protocol of communication via the Shared Memory , > JSON looks like a good universal format > > *Thanks* > > Big thanks to Eliot for inspiring me and Esteban for helping me figure out > things. > -- Best regards, Igor Stasenko.
Re: [Pharo-users] about balkanisation
On 6 November 2016 at 17:21, Stephan Eggermont <step...@stack.nl> wrote: > Kilon wrote: > > If you really want to embrace Github , kill Smalltalkhub > > We are not close to doing that. We'll need > Monticello support indefinitely, and at least a few years two-way. And > that assumes we automatically migrate all open projects. > > First we need good workflows that also work for complex projects. That > includes cross-platform projects like Seaside > > Oh, come on! Throw away everything you had.. and start using something new and trendy, rinse and repeat. Profit! :) > Stephan > > > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] How does Boolean ifTrue work?
On 3 November 2016 at 22:36, p...@highoctane.be <p...@highoctane.be> wrote:
> "not realizing, that they built a perfect jail for themselves, without
> any means to escape from it and do something in real world."
>
> Right on Igor. I hate jails. Pharo is such a breath of fresh air. I can
> kill myself in all kinds of ways, each of which led a step further on the
> path towards enlightment in coderland.
>
> Pharo|Smalltalk: also acts as a pretty good coder filter.
>
>
And languages like Java forcing you to learn bad code practices, right from
the beginning, when you to make a subclass of something have to write
'extends',
that completely misleads you:
class Subclass extends Base { ...
because subclassing is not synonym of extending , it is a synonym of
inheriting. You cannot 'extend' the behavior of parent class in your
subclass, in fact, each time you make subclass, you are specializing more
and more and hence, you actually narrowing down the potential uses of your
instances.. How does that 'extending' complies with narrowing??
Phil
>
>
> --
Best regards,
Igor Stasenko.
Re: [Pharo-users] How does Boolean ifTrue work?
On 3 November 2016 at 22:36, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > Igor you confuse me with someone else I never asked why Smalltalk doesn't > have... nor I said that I want static types and interfaces. I am actually > trying to use a Pharo instead of C++ with Unreal. > > I hate static types and I hate interfaces. Only pointed that is possible. > I don't like languages that think they are smarter than me. I love my > freedom thank you very much and I love Pharo as it is language wise. > sorry, i confused you with the original question of CodeDmitry. > On Thu, 3 Nov 2016 at 23:16, Igor Stasenko <siguc...@gmail.com> wrote: > >> On 3 November 2016 at 07:11, Dimitris Chloupis <kilon.al...@gmail.com> >> wrote: >> >> Actually sorry Igor but you are wrong, you just defeated the purpose of >> Smalltalk. To expose you to the internals. Of course you can implement >> interfaces. You can even implement static types. You can do anything you >> want. >> >> >> So, why you asking then 'why smalltalk doesn't have ' when you know >> that in smalltalk you can do anything you want? >> Yes, you can do anything you want, but not everything you can do makes >> sense to do. >> And it doesn't defeats the purpose of smalltalk, it just defeats the >> common sense. >> >> And last one, i don't understand what kind of 'exposure to internals' you >> are talking about. >> In smalltalk people used to write a functional tests, to check that your >> code behaves as intended. Now you proposing to introduce static interfaces, >> borrowed from other lanuages, the only purpose of which is to declare that >> your code *could* behave as intended, no guarantees , nothing. >> Just a set of formal rules on top of existing ones, with ZERO end effect >> and benefits. >> You want it? You are free to implement it. Good look with it.. >> >> I wonder, why so many people think that if they put soft pillows >> everywhere, seal the doors (because outside is dangerous) , and after >> sealing and pillowing everything they happily rest with thought 'now we are >> safe'.. not realizing, that they built a perfect jail for themselves, >> without any means to escape from it and do something in real world. >> >> The compiler is written in Smalltalk after all. >> >> On Wed, 2 Nov 2016 at 23:02, Igor Stasenko <siguc...@gmail.com> wrote: >> >> >> If you want to ensure that your class(es) comply with certain protocol, >> just write a test that covers the protocol and checks that class instances >> will understand messages you want it to understand. >> But there's no way to restrict your class to comply to whole protocol >> once at a time, because tools made in a way, that you populating your class >> with methods, each method is add individually and compiled separately, and >> the only validation, the compiler is capable of is basically compliance >> with smalltalk syntax. And it doesn't cares about higher lever requirement, >> like whether your class turns to be 'valid' because of a method you just >> added, ready to be used and for what. >> Even more, there's no way to connect all those 'interface' formalisation >> garbage rules with send sites (the place where you actually invoking one or >> another method of one of potetial implementor of your interface), so it >> makes no sense to do any (pre)validation on whatever class/object in a >> system in order to check whether it conforms with it or not. >> That's " Why don't Smalltalk or Smalltalklike languages have checked >> interfaces?" >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.
Re: [Pharo-users] How does Boolean ifTrue work?
On 3 November 2016 at 07:11, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > Actually sorry Igor but you are wrong, you just defeated the purpose of > Smalltalk. To expose you to the internals. Of course you can implement > interfaces. You can even implement static types. You can do anything you > want. > > So, why you asking then 'why smalltalk doesn't have ' when you know that in smalltalk you can do anything you want? Yes, you can do anything you want, but not everything you can do makes sense to do. And it doesn't defeats the purpose of smalltalk, it just defeats the common sense. And last one, i don't understand what kind of 'exposure to internals' you are talking about. In smalltalk people used to write a functional tests, to check that your code behaves as intended. Now you proposing to introduce static interfaces, borrowed from other lanuages, the only purpose of which is to declare that your code *could* behave as intended, no guarantees , nothing. Just a set of formal rules on top of existing ones, with ZERO end effect and benefits. You want it? You are free to implement it. Good look with it.. I wonder, why so many people think that if they put soft pillows everywhere, seal the doors (because outside is dangerous) , and after sealing and pillowing everything they happily rest with thought 'now we are safe'.. not realizing, that they built a perfect jail for themselves, without any means to escape from it and do something in real world. The compiler is written in Smalltalk after all. > > On Wed, 2 Nov 2016 at 23:02, Igor Stasenko <siguc...@gmail.com> wrote: > > > If you want to ensure that your class(es) comply with certain protocol, > just write a test that covers the protocol and checks that class instances > will understand messages you want it to understand. > But there's no way to restrict your class to comply to whole protocol once > at a time, because tools made in a way, that you populating your class with > methods, each method is add individually and compiled separately, and the > only validation, the compiler is capable of is basically compliance with > smalltalk syntax. And it doesn't cares about higher lever requirement, like > whether your class turns to be 'valid' because of a method you just added, > ready to be used and for what. > Even more, there's no way to connect all those 'interface' formalisation > garbage rules with send sites (the place where you actually invoking one or > another method of one of potetial implementor of your interface), so it > makes no sense to do any (pre)validation on whatever class/object in a > system in order to check whether it conforms with it or not. > That's " Why don't Smalltalk or Smalltalklike languages have checked > interfaces?" > > -- > Best regards, > Igor Stasenko. > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] How does Boolean ifTrue work?
If you want to ensure that your class(es) comply with certain protocol, just write a test that covers the protocol and checks that class instances will understand messages you want it to understand. But there's no way to restrict your class to comply to whole protocol once at a time, because tools made in a way, that you populating your class with methods, each method is add individually and compiled separately, and the only validation, the compiler is capable of is basically compliance with smalltalk syntax. And it doesn't cares about higher lever requirement, like whether your class turns to be 'valid' because of a method you just added, ready to be used and for what. Even more, there's no way to connect all those 'interface' formalisation garbage rules with send sites (the place where you actually invoking one or another method of one of potetial implementor of your interface), so it makes no sense to do any (pre)validation on whatever class/object in a system in order to check whether it conforms with it or not. That's " Why don't Smalltalk or Smalltalklike languages have checked interfaces?" -- Best regards, Igor Stasenko.
Re: [Pharo-users] How does Boolean ifTrue work?
On 2 November 2016 at 20:36, Henrik Sperre Johansen < henrik.s.johan...@veloxit.no> wrote: > CodeDmitry wrote > > Why don't Smalltalk or Smalltalklike languages have checked interfaces? > > The compilation occurs at runtime but it is still technically a > > compilation, why don't languages allow implementing interfaces at > runtime? > > The type information is there, and the source can load the list of > > messages expected and check if the compiled class contains all members or > > removes it and throws an exception. Is this just too expensive? > > because it's smalltalk. and because you don't come into existing temple with own rules well.. i hope you will stay here a little bit longer, to learn and undestand, that what you proposing/asking for is ether already there in one or another form, or simply unnecessary. P.S. please forgive me for being rude, impatient and trollish towards newcomers.. but i just can't help with it. -- Best regards, Igor Stasenko.
Re: [Pharo-users] How does Boolean ifTrue work?
On 1 November 2016 at 17:00, p...@highoctane.be <p...@highoctane.be> wrote: > Hey Igor is around \o/ > Hey heya! :) > BTW using size = 0 triggers a code critic telling you to use isEmpty. > > Maybe there is a rule of isEmpty ifTrue: :-) > > I think that there could be a lot of convenience methods in the base > image. They can be in an extension protocol, no issue. STON and gt have a > ton of these. In the base image. > > About beginners, well: have a look in some Zinc code and learn a truckload > of tricks. Like inject: somePath into: ... etc. > > And when puzzled, Halt now and debug or inspect it go a long way in > figuring things out. > > As long as the method is intention revealing, what is the issue? > > At the risk of some flames, Pharo isn't bound to some Smalltalk > compatibility. And that is what is cool about it. We chose another path now > we have to go our way of else. > > Building on a great foundation is nice. But that doesn't equate to > following the Smalltalk canon IMHO. > > And now 64 bits becoming real with a nice FFI and pinned objects... that > is going to bring in a lot of non smalltalk stuff for sure. > > Phil > > well, if continue on that, i think that while #ifEmpty: is perfectly fine, the #ifEmptyOrNil: are not. And indeed, in this case im also inclined to see those as pollution. Because uninitialized state can (or better to say - *must*) happen in one form - either it is nil, or empty collection, but not both. If your code having entry points that treats both of those as some kind of uninitialized state, then i would call it bad. To my opinion, it is bad practice to declare 'my method(s) can deal with any shit you can throw into it'. Personally, i prefer to clearly state what it accepting and what not, and strongly discourage any other free-form inputs, or even better - making them impossible to appear, so you don't have to put #ifEmptyOrNilOrCrazy: everywhere to make your code idioto-proof :) And the stupidity-proofing is quite simple, use converters/validators immediately on passed external data: myMethod: externalData myValidState := externalData asSanelyCheckedData. so, like that you don't have to put: myValidState ifValidState: [] everywhere :) Le 1 nov. 2016 15:14, "Igor Stasenko" <siguc...@gmail.com> a écrit : > >> >> >> On 1 November 2016 at 11:31, jtuc...@objektfabrik.de < >> jtuc...@objektfabrik.de> wrote: >> >>> Phil, >>> >>> >>> I see your point but disagree. >>> I don't use Pharo regularly, so I cannot currently check if the >>> implementation around this emptiness check is complete. >>> >>> With complete I mean that following your logic, theere should be at >>> least implementations of >>> >>> ifEmpty: >>> ifNotEmpty: >>> ifEmpty:ifNotEmpty: >>> ifEmptyOrNil: >>> ifEmptyOrNil:otherwise: >>> >> >> why pollution? >> it just convenience method. mind you, that #isEmpty is also convenience >> method, without it you would do it like: >> >> myArray size isZero ifTrue: [] >> of wait.. #isZero also convenience method... so if you elitist then you >> have to write it like that: >> >> myArray size = 0 ifTrue: [] >> >> And that , to my opinion, adds even more pollution to the user code, >> because first, it is longer, and second >> #ifEmpty: much better clarifies the intent of author, comparing to size = >> 0 >> >> >>> I really have to check for the size of collections very often, and the >>> size of 1 is a very frequent case. So why not add: >>> >>> ifExactlyOne: >>> ifSizeIs:do: >>> ifSizeIsGreaterThan:do:otherwiseDo: >>> >>> You get the picture. I strongly believe this leads to pollution and ends >>> up in a mess. >>> We could save so much typing and make our programs so much more readable >>> if we only were a bit more creative, right? ;-) >>> A DSL is another story, though. If you write a Library that makes >>> handling Collections nicer, this is okay and the methods are good to exist >>> in its context. But they shouldn't necessarily all be part of the base >>> image. >>> >>> >>> Don't get me wrong: if you and the Pharo community agree on lots of >>> convenience methods, that is okay for me, and I find myself adding such >>> methods to VA Smalltalk from time to time. I appreciate many of them being >>> brought to VA ST in Grease. >>> >>> Sometimes, this is simply a question of taste, sometimes it saves >>> typing, sometimes it helps to improve readabili
Re: [Pharo-users] How does Boolean ifTrue work?
On 1 November 2016 at 11:31, jtuc...@objektfabrik.de < jtuc...@objektfabrik.de> wrote: > Phil, > > > I see your point but disagree. > I don't use Pharo regularly, so I cannot currently check if the > implementation around this emptiness check is complete. > > With complete I mean that following your logic, theere should be at least > implementations of > > ifEmpty: > ifNotEmpty: > ifEmpty:ifNotEmpty: > ifEmptyOrNil: > ifEmptyOrNil:otherwise: > why pollution? it just convenience method. mind you, that #isEmpty is also convenience method, without it you would do it like: myArray size isZero ifTrue: [] of wait.. #isZero also convenience method... so if you elitist then you have to write it like that: myArray size = 0 ifTrue: [] And that , to my opinion, adds even more pollution to the user code, because first, it is longer, and second #ifEmpty: much better clarifies the intent of author, comparing to size = 0 > I really have to check for the size of collections very often, and the > size of 1 is a very frequent case. So why not add: > > ifExactlyOne: > ifSizeIs:do: > ifSizeIsGreaterThan:do:otherwiseDo: > > You get the picture. I strongly believe this leads to pollution and ends > up in a mess. > We could save so much typing and make our programs so much more readable > if we only were a bit more creative, right? ;-) > A DSL is another story, though. If you write a Library that makes handling > Collections nicer, this is okay and the methods are good to exist in its > context. But they shouldn't necessarily all be part of the base image. > > > Don't get me wrong: if you and the Pharo community agree on lots of > convenience methods, that is okay for me, and I find myself adding such > methods to VA Smalltalk from time to time. I appreciate many of them being > brought to VA ST in Grease. > > Sometimes, this is simply a question of taste, sometimes it saves typing, > sometimes it helps to improve readability of code. > > But I wouldn't go so far to tell people they should better use such a > method as a general advice. I would probably tell them: "look, here's a > method I find much more elegant, you could *also* use that to save > typing/increase readability". > > Just my 2 cents, and highly off topic ;-) > > Joachim > > > > > Am 01.11.16 um 08:43 schrieb p...@highoctane.be: > > Because I grew tired of the isEmpty ifTrue: [ ] all over the place. > And ifEmpty has the right semantics for my use cases (like assignment). > > I do not really care about portability, I am doing Pharo only. > > Phil > > On Mon, Oct 31, 2016 at 5:30 PM, jtuc...@objektfabrik.de < > jtuc...@objektfabrik.de> wrote: > >> Am 31.10.16 um 15:59 schrieb p...@highoctane.be: >> >> but you should use myCollection ifEmpty: [ ... ] >> >> >> interesting. Why do you think so? what if you wanted your code to be >> portable across Smalltalk dialects? >> >> >> >>> >>> >>> >> >> >> -- >> --- >> Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de >> <jtuc...@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 >> >> >> -- > ------- > Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de > <jtuc...@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 > > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] OpenGL project
On 1 April 2016 at 13:23, Thibault Raffaillac <thibault.raffail...@inria.fr> wrote: > There's (hopefully!) no question of throwing it away already. That > represents too much work, and pretty good design choices IMO. Yet I'm still > pretty new to Pharo/Smalltalk so simply need time. At the moment I am only > practicing on a GLFW binding. > Now, I do believe in OpenGL and hardware rendering in general (vs software > & framebuffer stuff), but these APIs are constantly evolving (with > hardware, market needs, ...), with driver manufacturers having little care > about backward compatibility. This means in that sea of innovations we have > to spot the few key technologies which are going to last long enough to be > still in use by the time they reach Pharo users (think of tesselation, or > geometry shaders, hardly heard of nowadays). OpenGL ES 2 is such a key > tech, I think, for its wide adoption in Android, iOS, RasPi. Still, there > is no doubt it is going to be ditched too in a decade or so (command > buffers are already being reintroduced in Vulkan...), and then in Pharo. > With that in mind, my point is to make it as few and small classes as > possible, to make it easier (and faster!) to ditch them later when a new > key tech arises. > That said, I'm looking for least effort solution, so will still strive to > replace NB with UFFI in generator. > > Hi, Thibault.. don't get me wrong: i am fully supporting any effort to bring cool and fast and fancy graphics tech to Pharo. So, nice to hear from you! There's not much effort in generating calls to numerous GL function - it just a matter of parsing opengl spec and producing appropriate smalltalk code out of it.. The main hurdle, i guess, you may find is service code and GL context wrappers i made to handle extension(s) and dealing with the fact that different extensions may or may not be available depending what kind of context you created. I did it by instantiating a table of function pointers and making a specialized custom ffi callout mechanism, that instead of standard way - looking up for a function pointer once and for the rest of session, doing it individually on a per-context basis. That ensures that you can use different contexts safely without risk of calling a function that is not supported in current context while it was supported in another context, one that you used just before. I don't know how you could preserve such kind of functionality in UFFI.. the only thing i know is that you are much more limited in choice. Sure it could be done.. but would it be as efficient as before (just one extra pointer lookup in table of pointers before making a call)? So, that's what i worry about. Cheers, > Thibault > > > Why cutting things down to a subset? > > You have all specs on Opengl.org .. all you have to do today is to import > > xml file and generate proper ffi calls. You can, of course, add support > of > > OpenGL ES.. but why throwing away rest of spec? It just a spec.. you > don't > > have to use it if you don't need it. Instead, if that feels too big - > you > > can do it smarter way: > > - make package/subpackage/classes for ES edition and for full edition. > > It shouldn't cause much trouble if you do it right. > > Because throwing away is easiest part - but making something that will > > serve for years .. harder, because tomorrow someone else can come and > throw > > your stuff away :) > > OpenGL is around for years now.. and i don't think ES edition will > replace > > standard.. I would prefer to be able to access to full OpenGL > > functionality, at a day i will need it.. why cutting things down? > > > > There's many ways to do things in smart way so, nothing will be lost. > > If you don't want/can't maintain or support full OpenGL support - that's > > another story. Then just don't call your project OpenGL - it will cause > > confusion to those who expecting things to work out of the box, and > finding > > out it just OpenGL ES.. > > > > > > > My advise is don't worry about backward compatibility , make it easy, > make > > > it simple. Don't be afraid to code some of it in C if you have to. > > > Sometimes it's far easier to use C than Pharo. Pharo is no magic wand. > > > > > > > > Yep, make it work. That's all what matters. > > -- Best regards, Igor Stasenko.
Re: [Pharo-users] OpenGL project
On 25 March 2016 at 12:51, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > Better name it "Pharo OpenGL ES" so people don't get confused why some of > their OpenGL code does not work. You won't finds docs about it , the guy > that made it rarely frequents this forums anymore and his code is based on > a api that is no longer included and supported by Pharo because it was > doing a lot of machine code stuff that was very hard to maintain. > > Why cutting things down to a subset? You have all specs on Opengl.org .. all you have to do today is to import xml file and generate proper ffi calls. You can, of course, add support of OpenGL ES.. but why throwing away rest of spec? It just a spec.. you don't have to use it if you don't need it. Instead, if that feels too big - you can do it smarter way: - make package/subpackage/classes for ES edition and for full edition. It shouldn't cause much trouble if you do it right. Because throwing away is easiest part - but making something that will serve for years .. harder, because tomorrow someone else can come and throw your stuff away :) OpenGL is around for years now.. and i don't think ES edition will replace standard.. I would prefer to be able to access to full OpenGL functionality, at a day i will need it.. why cutting things down? There's many ways to do things in smart way so, nothing will be lost. If you don't want/can't maintain or support full OpenGL support - that's another story. Then just don't call your project OpenGL - it will cause confusion to those who expecting things to work out of the box, and finding out it just OpenGL ES.. > My advise is don't worry about backward compatibility , make it easy, make > it simple. Don't be afraid to code some of it in C if you have to. > Sometimes it's far easier to use C than Pharo. Pharo is no magic wand. > > Yep, make it work. That's all what matters. > And foremost ask a ton of questions. We love questions. > On Fri, 25 Mar 2016 at 11:38, Thibault Raffaillac < > thibault.raffail...@inria.fr> wrote: > >> > Can you include a proper build script? >> >> Yep sorry, here are the steps I used to make it run on OSX: >> $ brew install glfw3 >> $ cc demo.c -lglfw3 -framework OpenGL >> >> For other systems the doc is hopefully detailed enough ( >> http://www.glfw.org/docs/latest/build.html). >> >> > Why do you say ?porting NBOpenGL?? Is it just a matter of rewriting the >> > native calls with the new FFI system? >> NBOpenGL functions were generated automatically from NBGLGenerator, so I >> need to get used to the tool beforehand. It looks like a lot of work was >> put into this, can I find a paper about it? >> Also, IMO this all looks too complex. My point in limiting to ES 2 is not >> just removing functions, I want to make it look simple like the C demo! >> >> Thibault >> >> -- Best regards, Igor Stasenko.
Re: [Pharo-users] NativeBoost and variadic functions
And let me remind you that despite that NB implements FFI to speak with C, it is not obliged to implement features of C language itself. It lets you speak with C programs, but not lets you write programs like in C (see the difference? :) I wasn't implying that implicit type conversion was a good thing that needed implementing -- but just a bump if it hadn't needed attention to it before when C did it automagically. cheers -ben Of course, Ben, i understand that you may miss some of the feature(s), you get used to when doing things in C. But then consider what is involved to implement such feature because it means determining argument types at run time (at compile time it is impossible as well as 'compile once when it is invoked for the first time' that NB does ) That means that no matter how well you try, the implementation will suck.. because it will be very slow comparing to one that uses fixed-type fixed-argument number. My philosophy , in general, for programming is avoid bloat and inefficiency at all costs. When some feature requires bloat and going to be very inefficient, i simply saying 'No'. Especially at infrastructural level, which NB belongs to. Because one thing that you (of me) as implementer knows what is fast cool and what is slow inefficient, but then users come and start using things in a way you would never think your stuff will be ever used.. and start spreading inefficiency in their project(s). And more that that, once they get used to it, then you would be never able to remove it because it is there and everyone using it and some even loving it :) -- Best regards, Igor Stasenko.
Re: [Pharo-users] NativeBoost and variadic functions
On 15 July 2015 at 11:16, Matthieu Lacaton matthieu.laca...@gmail.com
wrote:
Hello Igor,
Thanks for your answer.
I implemented something like that for the printf function:
Basically, it generates a method with matching arguments and executes it.
*printf:* stringFormat *args:* tab
| argNumber functionArgs functionPrototype methodCorpse
methodSelector argsArray |
((tab size % 2) = 0) ifFalse: [
Transcript show: 'error'.
^self.
].
argNumber := 0.
functionPrototype := 'printf: stringFormat'.
functionArgs := ''.
methodCorpse := ''.
argsArray := (Array new: (tab size / 2) + 1).
argsArray at: 1 put: stringFormat.
1 to: tab size by: 2 do: [ :i |
functionPrototype := functionPrototype, ' arg', argNumber
asString, ': ', (tab at: i) asString, argNumber asString.
functionArgs := functionArgs, ' ', (tab at: i) asString, ' ',
(tab at: i) asString, argNumber asString, ','.
argsArray at: argNumber + 2 put: (tab at: i + 1).
argNumber := argNumber + 1.
].
functionArgs := functionArgs allButLast.
methodCorpse := functionPrototype, Character cr asString, '
primitive: #primitiveNativeCall module: #NativeBoostPlugin', Character cr
asString, Character cr asString, '^self nbCall: #( void printf ( String
stringFormat,', functionArgs asString, ' ) )', Character cr asString, '
module: NativeBoost CLibrary'.
methodSelector := self class compile: methodCorpse.
self perform: methodSelector withArguments: argsArray.
Then you can call it like that :
MyClass printf: 'Test of printf. String: %s, Int : %d, Long: %ld, Char:
%c, Double: %lf' args: { 'String'. 'This is a string'. 'int'. 100. 'long'.
1000. 'char'. 89. 'double'. 3.14159 }.
I also tried it for some other variadic functions and, on my computer (I
am running archlinux), it seemed to work for every type of argument except
float. It works fine for double though.
For char you need to pass the integer ASCII value directly for it to
work. I tried with Character value: xxx but it didn't work.
I know that this is very hackish and very bad, and I am aware it has some
drawbacks. Moreover I am not even sure it will work everytime.
But for now it seems to work ...
Oh man...
and why would anyone may want to use this? :)
Sure you can do whatever it takes to implement a feature you want so badly,
but hey..
If something that takes so much effort and so inefficient as result, would
you consider abandon the idea and use something else instead? :)
Because it is straightly against the philosophy of NB: be fast and explicit.
And you seem to be in favor of implicitness.
Well, nevertheless, it is a honorable goal, so good luck :)
2015-07-13 19:24 GMT+02:00 Igor Stasenko siguc...@gmail.com:
On 10 July 2015 at 10:18, Matthieu Lacaton matthieu.laca...@gmail.com
wrote:
Hello,
Is it possible with NativeBoost to create a binding for a variadic
function ?
I've seen the printf example in NBCPrinter but this implementation is
kind of cheating since it always pass just a %s as format and one already
formatted string to the C function.
I've written a simple variadic function which adds every integer it
receives as argument (first argument is for the number of following
arguments) :
int add(int number,...);
In Pharo I've tried something like this :
*add: *number *arg1: *first *arg2: *second
primitive: #primitiveNativeCall module: #NativeBoostPlugin
^ self nbCall: #( int add (int number, int first, int second))
module: 'libMyLib.so'
and it works fine with two arguments.
Basically, doing so, I would need one method per number of arguments so
it's not very cool.
I thought that maybe I could pass an array as argument to my Pharo
method but I didn't really find a way to figure out how to define the
nbCall without having a Generic failure.
*add: *number *args: *anArray
primitive: #primitiveNativeCall module: #NativeBoostPlugin
^ self nbCall: #( int add (int number, ??? anArray))
module: 'libMyLib.so'
Do you have an idea ?
In short, there's no marshaller for converting an array of items, to same
number of things on stack. That could solve the problem with your example:
passing array of objects of *same* type. But in general, it is not what C
variadic function(s) standing for. Because they stand for any number of
arguments, of any type.
In C, since all program is compiled statically, compiler knows the number
of passed arguments and their types through compiling each particular call
site(s) to variadic function. Which means that in fact, you are still
supplying all information needed by compiler *before* run time.
In variadic functions, you can pass any arguments of any type,
but for converting each of them, you must tell NB what kind of
marshaller should be used for it , which means, that it is impossible to
know before run time, since you cannot know how many arguments
Re: [Pharo-users] NativeBoost and variadic functions
On 15 July 2015 at 16:35, Ben Coman b...@openinworld.com wrote:
On Wed, Jul 15, 2015 at 5:16 PM, Matthieu Lacaton
matthieu.laca...@gmail.com wrote:
Hello Igor,
Thanks for your answer.
I implemented something like that for the printf function:
Basically, it generates a method with matching arguments and executes it.
printf: stringFormat args: tab
| argNumber functionArgs functionPrototype methodCorpse
methodSelector
argsArray |
((tab size % 2) = 0) ifFalse: [
Transcript show: 'error'.
^self.
].
argNumber := 0.
functionPrototype := 'printf: stringFormat'.
functionArgs := ''.
methodCorpse := ''.
argsArray := (Array new: (tab size / 2) + 1).
argsArray at: 1 put: stringFormat.
1 to: tab size by: 2 do: [ :i |
functionPrototype := functionPrototype, ' arg', argNumber
asString, ': ', (tab at: i) asString, argNumber asString.
functionArgs := functionArgs, ' ', (tab at: i) asString, ' ',
(tab
at: i) asString, argNumber asString, ','.
argsArray at: argNumber + 2 put: (tab at: i + 1).
argNumber := argNumber + 1.
].
functionArgs := functionArgs allButLast.
methodCorpse := functionPrototype, Character cr asString, '
primitive: #primitiveNativeCall module: #NativeBoostPlugin',
Character cr
asString, Character cr asString, '^self nbCall: #( void printf (
String
stringFormat,', functionArgs asString, ' ) )', Character cr asString, '
module: NativeBoost CLibrary'.
methodSelector := self class compile: methodCorpse.
self perform: methodSelector withArguments: argsArray.
Then you can call it like that :
MyClass printf: 'Test of printf. String: %s, Int : %d, Long: %ld, Char:
%c,
Double: %lf' args: { 'String'. 'This is a string'. 'int'. 100. 'long'.
1000. 'char'. 89. 'double'. 3.14159 }.
I also tried it for some other variadic functions and, on my computer (I
am
running archlinux), it seemed to work for every type of argument except
float.
Maybe NativeBoost does not do implicit type conversions that a C
compiler would do?
It does not.
But that's not an issue. The philosophy behind NB was to require from user
explicit information about what types to use and how.
The main reason behind that, is that the more explicit and detailed
information you got at compilation time (in case of NB - code generation) ,
the more simple and efficient generated code will be.
In general, you don't want to generate trains of machine code to handle
1000+ of cases for converting a single argument (and then repeat the same
for next function argument). It makes things slow and inefficient, not
speaking that generated code also takes memory space.
I don't want to make code generation too smart, and this is why i trying to
avoid any implicitness: because else it makes users wonder why something
works and something don't and he have no idea, because of tons and tons of
contradicting implicit rules hidden behind the scenes.
And let me remind you that despite that NB implements FFI to speak with C,
it is not obliged to implement features of C language itself. It lets you
speak with C programs, but not lets you write programs like in C (see the
difference? :)
[1] Because C will promote floats to doubles for functions that take
variable arguments
More info search [2] for:
* implicit type conversion
* guess wrongly when the program uses floating-point formats in
scanf() or printf()
[1]
http://stackoverflow.com/questions/210590/why-does-scanf-need-lf-for-doubles-when-printf-is-okay-with-just-f
[2] http://www.electroons.com/8051/ebooks/expert%20C%20programming.pdf
cheers -ben
It works fine for double though.
For char you need to pass the integer ASCII value directly for it to
work.
I tried with Character value: xxx but it didn't work.
I know that this is very hackish and very bad, and I am aware it has some
drawbacks. Moreover I am not even sure it will work everytime.
But for now it seems to work ...
2015-07-13 19:24 GMT+02:00 Igor Stasenko siguc...@gmail.com:
On 10 July 2015 at 10:18, Matthieu Lacaton matthieu.laca...@gmail.com
wrote:
Hello,
Is it possible with NativeBoost to create a binding for a variadic
function ?
I've seen the printf example in NBCPrinter but this implementation is
kind of cheating since it always pass just a %s as format and one
already
formatted string to the C function.
I've written a simple variadic function which adds every integer it
receives as argument (first argument is for the number of following
arguments) :
int add(int number,...);
In Pharo I've tried something like this :
add: number arg1: first arg2: second
primitive: #primitiveNativeCall module: #NativeBoostPlugin
^ self nbCall: #( int add (int number, int first, int second))
module: 'libMyLib.so'
and it works fine with two arguments
Re: [Pharo-users] NativeBoost and variadic functions
On 10 July 2015 at 10:18, Matthieu Lacaton matthieu.laca...@gmail.com wrote: Hello, Is it possible with NativeBoost to create a binding for a variadic function ? I've seen the printf example in NBCPrinter but this implementation is kind of cheating since it always pass just a %s as format and one already formatted string to the C function. I've written a simple variadic function which adds every integer it receives as argument (first argument is for the number of following arguments) : int add(int number,...); In Pharo I've tried something like this : *add: *number *arg1: *first *arg2: *second primitive: #primitiveNativeCall module: #NativeBoostPlugin ^ self nbCall: #( int add (int number, int first, int second)) module: 'libMyLib.so' and it works fine with two arguments. Basically, doing so, I would need one method per number of arguments so it's not very cool. I thought that maybe I could pass an array as argument to my Pharo method but I didn't really find a way to figure out how to define the nbCall without having a Generic failure. *add: *number *args: *anArray primitive: #primitiveNativeCall module: #NativeBoostPlugin ^ self nbCall: #( int add (int number, ??? anArray)) module: 'libMyLib.so' Do you have an idea ? In short, there's no marshaller for converting an array of items, to same number of things on stack. That could solve the problem with your example: passing array of objects of *same* type. But in general, it is not what C variadic function(s) standing for. Because they stand for any number of arguments, of any type. In C, since all program is compiled statically, compiler knows the number of passed arguments and their types through compiling each particular call site(s) to variadic function. Which means that in fact, you are still supplying all information needed by compiler *before* run time. In variadic functions, you can pass any arguments of any type, but for converting each of them, you must tell NB what kind of marshaller should be used for it , which means, that it is impossible to know before run time, since you cannot know how many arguments you may pass, not speaking about their types. Thanks, Matthieu -- Best regards, Igor Stasenko.
Re: [Pharo-users] NativeBoost pointer and +
As i understand, in general, the problem that you described is in following:
- you want to pass an address of your buffer contents, but started not from
very first element of your buffer, but somewhere inside a buffer.
In smalltalk you cannot reference an element of array,
only the object (array in that case) as a whole.
The reason why it like so, because VM moves objects around, and you cannot
control directly when that happens,
and also VM responsible for updating all pointers (references) to moved
object(s)
for all interested parties (which could be other objects, stack etc) ,
making sure all references remain consistent upon such move.
So, with such constraints, the only way to validly point to an element
inside array
would be to store two values separately:
- a reference to an object, that represent your buffer (which VM would
update at will)
- an index (or offset) in that object, pointing to element in your buffer
Unfortunately, this is the only way how we could implement such, lets say
'ElementPointer' safely. Which then can be used to pass to C function(s),
converting object reference + offset into simple address just before
invoking a function (and sure thing, knowing that there's no chance
triggering GC, else it will turn into pointer to wrong place, but that's
general problem of passing pointers on object memory heap, not just
exclusively for 'element pointer' and such).
For buffers allocated externally, e.g. outside heap governed by VM,
there's nothing prevents you from having an address that pointing inside
some buffer (or even outside it :)
For NBExternalAddress:
addr := self allocate: somespace.
newAddr := NBExternalAddress value: addr value + someoffset.
or
newAddr := addr copy value: addr value + someoffset
sure, it is up to you then, how to calculate offsets and buffer size(s) as
well as allocating/deallocating memory for buffers you using.
On 8 June 2015 at 16:41, Matthieu Lacaton matthieu.laca...@gmail.com
wrote:
Hello everyone,
I have a small question about NativeBoost : How does the + operator when
applied to a pointer translates into NativeBoost code ?
To give a bit of context, what I want to do is to reallocate some
non-contiguous bytes in memory to a buffer. Basically, I have an array of
integers in a buffer and I want to copy some chunks of it in another
buffer. The chunks are always the same size and the offset between each
chunk is always the same too.
Because a bit of actual code is easier to understand here is what I'd like
to do in Pharo :
...
int i, j;
int *data = malloc(1000*sizeof(int));
int *newData = malloc(50*sizeof(int));
// Allocate initial data
for (i = 0 ; i 1000, i++) {
data[i] = i;
}
//Copy desired chunks into new buffer
for (i = 0; i 5; i++ ) {
memcpy( newData + j*10, data + 200 + j*30, 10*sizeof(int));
j++;
}
free(data);
...
Here basically I'll get in my buffer chunks of 10 integers starting at 200
with an offset of 30 between chunks, and this 5 times. (200 201 202 ... 208
209 230 231 ... 238 239 260 ... 328 329).
I am okay with the malloc, memcpy and free but I don't know how to handle
the + operator in my memcpy function.
Thank you,
Matthieu
--
Best regards,
Igor Stasenko.
Re: [Pharo-users] 'function unavailable' when calling OpenDBXDriver for MySQL
On 16 November 2014 23:46, bsselfri...@gmail.com bsselfri...@gmail.com wrote: I've used the instructions defined on the http://dbxtalk.smallworks.eu/; website to setup the OpenDBXDriver for a MySQL database. When I try to make a connection to the database, I'm getting the function unavailable. I have this working on a Ubuntu 14.04 32bit OS. I'm wondering if my problem is my 64bit Ubuntu or do I have other problems. My setup: Ubuntu 14.04 64bit. Pharo 3.0 libopendbx.so.1.2.0 i386 version could be that libopendbx links with other 32-bit drivers, which is missing in your system. try ldd libopendbx.so.1.2.0 and see if all required libs are present. (32-bit , of course) Brad Selfridge - Brad Selfridge -- View this message in context: http://forum.world.st/function-unavailable-when-calling-OpenDBXDriver-for-MySQL-tp4790564.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- Best regards, Igor Stasenko.
Re: [Pharo-users] running out of memory while processing a 220MB csv file with NeoCSVReader - tips?
Never ending memory consumption problem. Hopefully with 64-bit version of VM we'll have a way more space to waste and it could take more effort to put system on its knees. -- Best regards, Igor Stasenko.
Re: [Pharo-users] Pharo on retina macbook
on retina, the display bitmap are 2x scaled. On 4 September 2014 09:56, Tudor Girba tu...@tudorgirba.com wrote: Hi, This should be a known issue as it was raised before. The problem occurs with any font. It has to do with the VM as far as I understood. I am not sure what is needed to be done, though. Cheers, Doru On Thu, Sep 4, 2014 at 9:20 AM, Ben Coman b...@openinworld.com wrote: Johan Brichau wrote: Hi, I just started using a Macbook pro with retina display. I notice the fonts are quite blurry. Is there something one can do to improve that? Johan What version of Pharo? What version of OSX? What fonts? I'm not sure of these details, but it will give you some things to think about and try (and someone can correct me otherwise). * Pharo's default font is still a bitmap StikeFont. * StrikeFont bitmaps are sub-pixel anti-aliased. * Sub-pixel anti-aliases * Retina display sometimes have sub-pixel rendering turned off, or maybe otherwise problem. Try... * Choosing a TrueType font * Changing some OSX display settings * http://graphicdesign.stackexchange.com/questions/ 8277/how-does-apples-retina-display-affect-sub-pixel-rendering * http://superuser.com/questions/457153/getting- crisper-fonts-in-os-x-after-switching-from-windows * http://www.macworld.com/article/1145157/smoothsnow.html * http://graphicdesign.stackexchange.com/questions/ 8277/how-does-apples-retina-display-affect-sub-pixel-rendering Please report your results. cheers -ben -- www.tudorgirba.com Every thing has its own flow -- Best regards, Igor Stasenko.
Re: [Pharo-users] Pharo on retina macbook
i'm wrong.. it scales only on ipads.. not on OS X. On 4 September 2014 11:09, Igor Stasenko siguc...@gmail.com wrote: on retina, the display bitmap are 2x scaled. On 4 September 2014 09:56, Tudor Girba tu...@tudorgirba.com wrote: Hi, This should be a known issue as it was raised before. The problem occurs with any font. It has to do with the VM as far as I understood. I am not sure what is needed to be done, though. Cheers, Doru On Thu, Sep 4, 2014 at 9:20 AM, Ben Coman b...@openinworld.com wrote: Johan Brichau wrote: Hi, I just started using a Macbook pro with retina display. I notice the fonts are quite blurry. Is there something one can do to improve that? Johan What version of Pharo? What version of OSX? What fonts? I'm not sure of these details, but it will give you some things to think about and try (and someone can correct me otherwise). * Pharo's default font is still a bitmap StikeFont. * StrikeFont bitmaps are sub-pixel anti-aliased. * Sub-pixel anti-aliases * Retina display sometimes have sub-pixel rendering turned off, or maybe otherwise problem. Try... * Choosing a TrueType font * Changing some OSX display settings * http://graphicdesign.stackexchange.com/questions/ 8277/how-does-apples-retina-display-affect-sub-pixel-rendering * http://superuser.com/questions/457153/getting- crisper-fonts-in-os-x-after-switching-from-windows * http://www.macworld.com/article/1145157/smoothsnow.html * http://graphicdesign.stackexchange.com/questions/ 8277/how-does-apples-retina-display-affect-sub-pixel-rendering Please report your results. cheers -ben -- www.tudorgirba.com Every thing has its own flow -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.
Re: [Pharo-users] NativeBoost: use of array
On 4 August 2014 16:45, Thomas Bany mun.sys...@gmail.com wrote: Hi again ! I'm having trouble to call the function with the following prototype : void propagateTLE(orbit_t orb, double secondSince[], xyz_t * out, size_t nbEpoch) with the corresponding NB call: self nbCall: #( void propagateTLE(orbit_t orbit, double * secondSince, xyz_t * out, size_t nbEpoch) ) The argument *secondSince* is an input and the argument *out* is the output pointer that the function should fill. I have made 2 subclass of NBExternalArray to feed this function, (allmost) namely: *ArrayOfDoubles *and *ArrayOfXYZ*. Should I mention that type *xyz_t* is a struct that I modeled with an *NBExternalStructure*. I face 2 issues: - The type *ArrayOfXYZ* is refused as an *xyz_t** type. However, the *ArrayOfDoubles *is accepted as a *double** type. - If a get rid of the *out* argument to test the array *secondSince*, I get an undefined error (Error durring FFI call: nil). My current solution is to use the adress of my arrays and the following NB call: self nbCall: #( void propagateTLE(orbit_t orbit, NBExternalAddress secondSince, NBExternalAddress out, size_t nbEpoch) ) if you explicitly specify NBExternalAddress, then it won't accept any other argument than instance of NBExternalAddress. Also, note there's no marshallers for (sub)instances of NBExternalArray, and thus you cannot pass them directly, but only by passing pointer to its elements using #address method. I.e, if you using 'whatever *', you can pass a pointer to array by: myArray address. But it feels like I'm cheating my way trough, by pretty much avoiding any type check. Any clue as to why the typecheck of NB is refusing to call my function ? Thanks in advance, Thomas. -- Best regards, Igor Stasenko.
Re: [Pharo-users] NativeBoost: structure with different types
On 4 August 2014 12:37, Thomas Bany mun.sys...@gmail.com wrote:
Hi everyone !
I experience troubles with NBExternalStructure in NativeBoost when the
structure modeled contains fields with different types. For example,
manipulating the following structure poses no problem and I can manipulate
the fields correctly:
typedef struct abc_s {
double a;
double b;
double c;
} abc;
However, setting field 'a' to be an int yields the following symptoms:
¤ From Pharo to C (function with 'abc' as argument type), the fields are
badly read.
¤ From C to Pharo (function with 'abc' as return type), the VM crash
without an error nor a dump.
Am I doing something wrong or is it maybe specific to the compiler I use
(the one that comes with Visual Studio Express 2013) ?
This caused by wrong alignment of structure in memory. Different compilers
can align structures differently, and there's no way to know it at run time.
Try to change the #
*byteAlignment of the structure.Also, if nothing helps, you can use dummy
fields* for padding fields, like in your example:
int a;
int dummy;
double b;
double c;
I'm pretty sure I could go arround this using NBExternalObject and
building the structure on C side, but it would be nice to avoid it.
On a side note, my understanding is that creating a structure on Pharo
side will have it stored in Pharo memory. Is it problematic when it comes
to pass it by value ? Or should I manage the copying on the C heap to be
safe ?
Thomas.
--
Best regards,
Igor Stasenko.
Re: [Pharo-users] String artifact in Athens canvas
On 16 June 2014 21:54, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: I got this problem in built image for production using a specific font. In my devel, environment with other I don't have this problem. Now in previous release of DrGeo I was using this same specific font and the problem was not there. I just ask to see if other have simimilar problems. I need to check further, but I am just exhausted for now. do you use same font within morphic UI? remember there was a bug related to it. Hilaire Le 16/06/2014 10:36, stepharo a écrit : It looks like this is related to the font information. could you show the same situation with different fonts? On 15/6/14 21:35, Hilaire Fernandes wrote: Hello, I am experiencing string artifact in athens canvas. It was not there with pure morphic canvas and the same font. See screen shot Thanks Hilaire -- Dr. Geo http://drgeo.eu iStoa - https://launchpad.net/istoa -- Best regards, Igor Stasenko.
Re: [Pharo-users] NativeBoost
On 30 April 2014 11:09, Markus Fritsche mfrits...@reauktion.de wrote: On 2014-04-30 04:58, Igor Stasenko wrote: NBFFICalloutforeignCall: aBlock callInfo := self newCallInfo. callInfo alignment: 16. asm performingCall: callInfo in: aBlock. while use: NativeBoostWin32stackAlignment ^ 1 This seems to work - however, I did not to subsequent calls. did not what? and then swap values. That crashes instantaneously. So, it seems that it is DLL function wants stack alignment. Best regards, Markus -- Best regards, Igor Stasenko.
Re: [Pharo-users] NativeBoost
On 30 April 2014 11:46, Markus Fritsche mfrits...@reauktion.de wrote: On 2014-04-30 11:35, Igor Stasenko wrote: So, it seems that it is DLL function wants stack alignment. So does that mean (doing it the right way) that I will have to change my stackAlignment method or do I have to use different nbCall-sonventions? It is safer to change it for whole platform, e.g in: NativeBoostWin32stackAlignment Best regards, Markus -- Best regards, Igor Stasenko.
Re: [Pharo-users] TextInputField in Spec size issue 12915 (was: dynamic example for spec)
try using 'self font:'? MorphicTextAdaptor supports this protocol. On 30 April 2014 15:19, Stephan Eggermont step...@stack.nl wrote: I can set the font in MorphicTextInputFieldAdapter adapt: aModel super adapt: aModel. aModel whenBuiltDo: [ :w | w widget color: Color white. w widget widget textMorph setTextStyle: TextStyle default ] but then still have the wrong cursor size and position. Stephan -- Best regards, Igor Stasenko.
Re: [Pharo-users] NativeBoost
On 29 April 2014 20:54, Markus Fritsche mfrits...@reauktion.de wrote: Hello Igor, I did change my class (tbh, I was just looking at the Cairo stuff and did some cargo cult programming). NBFFICallout new resolveType: #TM1U prints TM1U NBFFICallout new resolveType: #TM1P prints TM1P - my DoIt still gives NBExternalType I attached the resulting CompiledMethod as a fuel serialized file. What can I look at more deeply? i don't know what is going on.. everything looks correct.. as a workaround, you can change the return type of offending call to return uint, and then you can manually convert it to instance of TM1P with corresponding handle value. Also, i doubt it, but try change the alignment NativeBoostWin32stackAlignment to use 16 P.S. the fuel file with compiled method is not really helpful - it gives me an error during materialization. Thank you for your patience, Markus On 29.04.2014 00:36, Igor Stasenko wrote: Object subclass: #TM1U uses: TTM1ApiLibrary instanceVariableNames: 'handle' classVariableNames: '' poolDictionaries: '' category: 'Cognos-TM1-Api' hmm.. why just don't subclass from NBExternalObject? If you don't need to subclass from own base class, you can just subclass from NBExternalObject, which means you already having handle ivar, and #asNBExternalType: inherited at class side, tested and working..? So, try NBFFICallout new resolveType: #TM1U what it gives? On 28 April 2014 23:44, Markus Fritsche mfrits...@reauktion.de wrote: On 28.04.2014 13:30, Igor Stasenko wrote: This is strange.. should work fine. There's no way how NBExternalObjectType could return an instance of NBExternalHandle. Please check your code again. Been there, done that = thrown everything away and restarted the code from scratch... Sourcecode attached (the 32bit libraries are in the bin subdirectory, there's another bin64 directory) - is there anything obvious wrong with it?. Workspace: TM1LibraryLoader loadTM1Library. TM1Library tm1APIInitialize. hUser := TM1Library tm1SystemOpen. hPool1 := hUser tm1ValPoolCreate. hPool1 inspect. hUser tm1SystemClose. TM1Library tm1APIFinalize. The Inspector I get shows NBExternalHandle self@ 16r74CF4A8 (apparently it's fine for TM1U, otherwise tm1ValPoolCreate wouldn't be found) could it be inspector screwed? what hPool1 class gives? From the headers: #define TM1API __stdcall #ifndef TM1IMPORT #define TM1IMPORT __declspec( dllimport ) #endif typedef void * TM1U; // user handle typedef void * TM1P; // pool handle TM1IMPORT void TM1API TM1APIInitialize( void ); TM1IMPORT TM1U TM1API TM1SystemOpen( void ); TM1IMPORT TM1P TM1API TM1ValPoolCreate( TM1U hUser ); i don't see where you are using stdcall calling convention option? you should specify it either in code: self nbCallout stdCall function: #( TM1U TM1SystemOpen( ) ) module: or in the class with callout, implementing ffiCalloutOptions ^ #( + optStdcall ) (i think you can just put it into trait) In order to debug further I will have to redo the Windows VM. -- Best regards, Igor Stasenko.
Re: [Pharo-users] stepping a non-morphic object
On 29 April 2014 18:41, Sean P. DeNigris s...@clipperadams.com wrote: Chris Wright wrote What is the best way to get the step message sent to non-morphs - or is there a better way in Pharo I'm not sure I understand exactly, but if you want to do it via Morphic stepping, you could implement e.g. ModelTickingMorph which is invisible and has no extent, and steps your model in it's #step. or you could use a process: [ [ myModelObject step. 1 second asDelay wait ] repeat ] fork. except that you then will be also responsible for managing forked process by implementing it.. else it will loop forever, your object will never be GCed, consume CPU waste memory :) oh.. and each time you test it once more, it will readily spawn another process with same characteristics :) - Cheers, Sean -- View this message in context: http://forum.world.st/stepping-a-non-morphic-object-tp4756998p4757081.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- Best regards, Igor Stasenko.
Re: [Pharo-users] NativeBoost
On 26 April 2014 09:44, Markus Fritsche mfrits...@reauktion.de wrote: Hello, tl;dr: what's the reason to get aNBExternalHandle even if you expect a MySuperHandle object from an nbCall? I am trying to build my first DLL wrapper with NativeBoost. I am having a problem that instead of returning a handle object (as I thought), my primitive throws NBExternalHandles at me. The API I am trying to wrap tries to be somewhat object oriented by (mostly) having a handle of some sort. My thinking was to attach all DLL primitives to the respective Handle Objects they take as a first parameter and go from there. Some workspace code: Supplementary DLLs Tm1ULibDllLibraryLoader loadLibrary. LibIbmCogEayLibraryLoader loadLibrary. SslIbmCogEayLibraryLoader loadLibrary. Log4CxxLibraryLoader loadLibrary. DLL to wrap TM1LibraryLoader loadTM1Library. t := TM1Api new. t tm1APIInitialize. hUser := t tm1SystemOpen. Returns a proper 'TM1UHandle' object' hUser tm1SystemAdminHostSet: 'localhost'. hPool1 := hUser tm1ValPoolCreate. Returns NBExternalHandle hPool1 inspect. hUser tm1SystemClose. t tm1APIFinalize. TM1Api#tm1SystemOpen primitive: #primitiveNativeCall module: #NativeBoostPlugin ^ self nbCall: #(TM1UHandle TM1SystemOpen(void)) TM1UHandle#tm1ValPoolCreate primitive: #primitiveNativeCall module: #NativeBoostPlugin ^ self nbCall: #(#TM1PHandle TM1ValPoolCreate ( TM1UHandle self ) ) sidenote: when using 'self', you can use it without type. just say 'self', since it refers to the instance of method's class, which is enough to determine the type to use for marshalling. Both, TM1UHandle class and TM1PHandle class have the method asNBExternalType: gen use handle ivar to hold my instance (TM1x) ^ NBExternalObjectType objectClass: self and are subclasses of object. What's my mistake? Can you tell with the information I provided? This is strange.. should work fine. There's no way how NBExternalObjectType could return an instance of NBExternalHandle. Please check your code again. Best regards, Markus -- Best regards, Igor Stasenko.
Re: [Pharo-users] NativeBoost
Object subclass: #TM1U uses: TTM1ApiLibrary instanceVariableNames: 'handle' classVariableNames: '' poolDictionaries: '' category: 'Cognos-TM1-Api' hmm.. why just don't subclass from NBExternalObject? If you don't need to subclass from own base class, you can just subclass from NBExternalObject, which means you already having handle ivar, and #asNBExternalType: inherited at class side, tested and working..? So, try NBFFICallout new resolveType: #TM1U what it gives? On 28 April 2014 23:44, Markus Fritsche mfrits...@reauktion.de wrote: On 28.04.2014 13:30, Igor Stasenko wrote: This is strange.. should work fine. There's no way how NBExternalObjectType could return an instance of NBExternalHandle. Please check your code again. Been there, done that = thrown everything away and restarted the code from scratch... Sourcecode attached (the 32bit libraries are in the bin subdirectory, there's another bin64 directory) - is there anything obvious wrong with it?. Workspace: TM1LibraryLoader loadTM1Library. TM1Library tm1APIInitialize. hUser := TM1Library tm1SystemOpen. hPool1 := hUser tm1ValPoolCreate. hPool1 inspect. hUser tm1SystemClose. TM1Library tm1APIFinalize. The Inspector I get shows NBExternalHandle self@ 16r74CF4A8 (apparently it's fine for TM1U, otherwise tm1ValPoolCreate wouldn't be found) could it be inspector screwed? what hPool1 class gives? From the headers: #define TM1API __stdcall #ifndef TM1IMPORT #define TM1IMPORT __declspec( dllimport ) #endif typedef void * TM1U; // user handle typedef void * TM1P; // pool handle TM1IMPORT void TM1API TM1APIInitialize( void ); TM1IMPORT TM1U TM1API TM1SystemOpen( void ); TM1IMPORT TM1P TM1API TM1ValPoolCreate( TM1U hUser ); i don't see where you are using stdcall calling convention option? you should specify it either in code: self nbCallout stdCall function: #( TM1U TM1SystemOpen( ) ) module: or in the class with callout, implementing ffiCalloutOptions ^ #( + optStdcall ) (i think you can just put it into trait) In order to debug further I will have to redo the Windows VM. -- Best regards, Igor Stasenko.
Re: [Pharo-users] Athens and ellipse drawing
On 23 April 2014 13:17, Henrik Johansen henrik.s.johan...@veloxit.nowrote: On 22 Apr 2014, at 2:23 , Igor Stasenko siguc...@gmail.com wrote: as for why there's 4 arc segments instead of one, its because of bad approximation, when drawing more that 90 degree arcs. also, in athens, arc segment is defined with following inputs: - end point of previous segment (implicit) - angle - direction (clockwise/counterclockwise) - end point the radius, therefore calculated automatically, because with given set of parameters there's only one way to draw an arc connecting given points. Now if you put angle of 360 degrees, you cannot draw arc without specifying radius, because your end points will coincide, which means there's infinite number of ways to draw full circle passing through a single point, with any radius. cairo using different inputs for specifying arc segments.. - center, radius, start angle, end angle the problem with such parametrization is that it is completely separate from rest of commands (line/move/bezier etc).. and you will be very lucky if your arc will be connected with rest of your path.. because arc's starting point depends on start angle, instead of last point of previous path segment. this was the main reason to use more appropriate parametrization to get rid of inconsistency.. while losing ability to draw full circle with single command.. AFAICT, still doesn’t explain how to draw an ellipse with constant stroke path width, which was the original question :) Right, what is missing is elliptical arc segment type. And there's no direct support for it in Cairo.. so it can be only approximated by other segment types, like lines or bezier curves. There's a work started on calculating path geometry using approximation with line segments.. it can be used to represent any kind of curves defined parametrically. But it is not yet plugged into the API. One way is to not use a transformed circle path altogether, but draw the actual ellipsis path using cubic beziers: http://www.charlespetzold.com/blog/2012/12/Bezier-Circles-and-Bezier-Ellipses.html ellipsisOfExtent := [:builder :anExtent | | halfX halfY | halfX := anExtent x / 2. halfY := anExtent y / 2. “We expect relative builder, and start the ellipsis at anExtent x / 2 @ 0 builder curveVia: 0@(halfY negated * 0.55) and: (0.45 * halfX)@halfY negated to: halfX@ halfY negated; curveVia: halfX* 0.55 @ 0 and: halfX@ (0.45 * halfY) to: halfX @ halfY; curveVia: 0 @ (halfY * 0.55 ) and: (0.45 * halfX negated @ halfY) to: halfX negated @ halfY; curveVia: (halfX negated * 0.55) @ 0 and: halfX negated @ (halfY negated * 0.45) to: halfX negated @ halfY negated; close]. AthensSceneView new scene: [ :can | | path | path := can createPath: [ :builder | builder moveTo: 10@60. ellipsisOfExtent value: builder value: 200@100 ]. (can setStrokePaint: Color red) width: 8 asFloat. can drawShape: path ] ; openInWindow quite nice approximation. What is an error measure comparing to true ellipse? Cheers, Henry -- Best regards, Igor Stasenko.
Re: [Pharo-users] Athens question: AffineTransform, AthensCairoMatrix and Float values
On 11 April 2014 20:24, Juraj Kubelka juraj.kube...@gmail.com wrote: Thank you Igor, I understand and I agree. Just can you clarify one think. Maybe I use it wrong. Right now in Roassal2/Trachel a shape has instance variable called matrix which is an AthensAffineTransform object. And if someone calls translateBy:, or scaleBy:, etc. I call the appropriate method on AthensAffineTransform. Do you say, that I should rather have instance variables position, rotation, and scale? Do I understand well? I thought it is better (faster) to keep the matrix and in #drawOn: only call #multiplyBy:. it doesn't really matters.. and up to your convenience. sometimes it's convenient to use decomposed form (e.g. translation, scale, rotation) instead of full matrix, sometimes not.. depends how/who/where you using it. And another question. Right now a rectangle is drawn like this: -=-=-=-=- computePath canvas ifNil: [ ^ self ]. path := self athensCanvas createPath: [ :builder | builder absolute; moveTo: rectangle topLeft; lineTo: rectangle topRight; lineTo: rectangle bottomRight; lineTo: rectangle bottomLeft; lineTo: rectangle topLeft. ] -=-=-=-=- I do not see a method which draws rectangle directly. This examplehttp://zetcode.com/gfx/cairo/shapesfills/ shows there is a direct support for rectangle drawing. Am I right we do not have that support in Athens? Is there a reason for it? Because there's only one method which draws any kind of shapes (including rectangle). All you need to do is to draw it: canvas drawShape: (0@0 corner: 100@100). or canvas setShape: (0@0 corner: 100@100). ... canvas draw. else there would be need to add dozens of drawRect: drawOval: drawZigZag: drawAnotherWeirdThing: instead of simple method which covers all. Thank you, Juraj El 11-04-2014, a las 13:29, Igor Stasenko siguc...@gmail.com escribió: On 11 April 2014 17:41, Juraj Kubelka juraj.kube...@gmail.com wrote: Hi, We are integrating Athens transformation to Roassal2/Trachel and I have reached an issue. In drawing code I use something like this: -=-=-=- athensCanvas pathTransform restoreAfter: [ *athensCanvas pathTransform* *multiplyBy: matrix; “an instance of AthensAffineTransform* athensCanvas setPaint: color; drawShape: self path. -=-=-=- I have a problem, that sometimes it crashes because it expects a float value (I understand why). I suppose I do not have to keep float values in AthensAffineTransform object. My suggestion is to ensure float values where it is expected. For example the method #loadAffineTransform could be like this: -=-=-=- AthensCairoMatrixloadAffineTransform: m self initx: m x *asFloat* y: m y *asFloat* sx: m sx *asFloat* sy: m sy *asFloat* shx: m shx *asFloat* shy: m shy *asFloat* -=-=-=- Which will mean 6 extra #asFloat message sends, even if they're already floats or ints but not Fractions (and in 99% of cases they are, so you will slow down everything for the sake of 1%). I prefer that user supplies already prepared data, so it don't have to be implicitly converted since it takes extra CPU cycles, which can be spent somewhere else. But yes, it needs to be ensured, but at different place: where you building that AthensAffineTransform AthensAffineTransformsx: number sx := number = AthensAffineTransformsx: number sx := number asFloat .. (and for the rest of accessors) like that it will ensure that AthensAffineTransform always stores floats, which i'm not really like because integers is perfectly fine too.. its all about Fractions. Right now I have to do that transformation myself whenever I use Athens objects. I see it error prone and I do not see it obvious. On other hand I do not want to keep float values in my AthensAffineTransform, because if user do #scaleBy: 0.7 and then #scaleBy: (1/0.7) I want to get the same original value. Otherwise the image could change its size. On your place i'd better forget about it. That's impossible when you dealing with floating point values.. and multiple matrix operations. Unless you explicitly control it by yourself, but that certainly should be outside of AthensAffineTransform/Athens. The same change could be for other methods in AthensCairoMatrix. Again, that would mean dozens of extra message sends at every single place, whether it needed or not.. Like: AthensCairoMatrixtranslateX: px Y: py needs to be replaced with: ^ self primTranslateX: px asFloat Y: py asFloat instead of direct call, plus adding #primTranslateX:Y: method, of course. Do you really want to pay a price of 50% less performance (or more) in exchange of i don't wanna think what i passing to it? Because apparently, you always need to think what you passing - one cannot just pass a random object to some method and expect it to work, isn't? Because i don't. All you need is to avoid using Fractions.. because integers or floats is perfectly fine. Fraction created only if you use division on integer
Re: [Pharo-users] Athens question: AffineTransform, AthensCairoMatrix and Float values
On 11 April 2014 17:41, Juraj Kubelka juraj.kube...@gmail.com wrote: Hi, We are integrating Athens transformation to Roassal2/Trachel and I have reached an issue. In drawing code I use something like this: -=-=-=- athensCanvas pathTransform restoreAfter: [ *athensCanvas pathTransform* *multiplyBy: matrix; “an instance of AthensAffineTransform* athensCanvas setPaint: color; drawShape: self path. -=-=-=- I have a problem, that sometimes it crashes because it expects a float value (I understand why). I suppose I do not have to keep float values in AthensAffineTransform object. My suggestion is to ensure float values where it is expected. For example the method #loadAffineTransform could be like this: -=-=-=- AthensCairoMatrixloadAffineTransform: m self initx: m x *asFloat* y: m y *asFloat* sx: m sx *asFloat* sy: m sy *asFloat* shx: m shx *asFloat* shy: m shy *asFloat* -=-=-=- Which will mean 6 extra #asFloat message sends, even if they're already floats or ints but not Fractions (and in 99% of cases they are, so you will slow down everything for the sake of 1%). I prefer that user supplies already prepared data, so it don't have to be implicitly converted since it takes extra CPU cycles, which can be spent somewhere else. But yes, it needs to be ensured, but at different place: where you building that AthensAffineTransform AthensAffineTransformsx: number sx := number = AthensAffineTransformsx: number sx := number asFloat .. (and for the rest of accessors) like that it will ensure that AthensAffineTransform always stores floats, which i'm not really like because integers is perfectly fine too.. its all about Fractions. Right now I have to do that transformation myself whenever I use Athens objects. I see it error prone and I do not see it obvious. On other hand I do not want to keep float values in my AthensAffineTransform, because if user do #scaleBy: 0.7 and then #scaleBy: (1/0.7) I want to get the same original value. Otherwise the image could change its size. On your place i'd better forget about it. That's impossible when you dealing with floating point values.. and multiple matrix operations. Unless you explicitly control it by yourself, but that certainly should be outside of AthensAffineTransform/Athens. The same change could be for other methods in AthensCairoMatrix. Again, that would mean dozens of extra message sends at every single place, whether it needed or not.. Like: AthensCairoMatrixtranslateX: px Y: py needs to be replaced with: ^ self primTranslateX: px asFloat Y: py asFloat instead of direct call, plus adding #primTranslateX:Y: method, of course. Do you really want to pay a price of 50% less performance (or more) in exchange of i don't wanna think what i passing to it? Because apparently, you always need to think what you passing - one cannot just pass a random object to some method and expect it to work, isn't? Because i don't. All you need is to avoid using Fractions.. because integers or floats is perfectly fine. Fraction created only if you use division on integer.. so all you need to do is to ensure the result of division is float: (x/y) asFloat. What do you think? I am biased towards having better performance, even at cost of inconvenience, where at some places i have to ensure i need to pass correct value(s). Juraj -- Best regards, Igor Stasenko.
Re: [Pharo-users] Athens and ellipse drawing
yes, you using stroke for 2nd ellipse, but stroke width is also subject of scaling, that's why it has different width, because of non-uniform scaling (x/y). instead you can first, draw a filled ellipse (blue) and then draw green one over it. On 11 April 2014 21:33, Juraj Kubelka juraj.kube...@gmail.com wrote: Hi Igor, hi all! I am not sure how to properly draw ellipse. Right now I draw a path like this: The path is created that way: -=-=-=-=- computePath path := self athensCanvas createPath: [ :builder | builder absolute; moveTo: 0 @ 0.5; ccwArcTo: 0.5 @ 0.0 angle: 90 degreesToRadians; ccwArcTo: 0.0 @ -0.5 angle: 90 degreesToRadians; ccwArcTo: -0.5 @ 0.0 angle: 90 degreesToRadians; ccwArcTo: 0 @ 0.5 angle: 90 degreesToRadians ] -=-=-=-=- And draw it like this: -=-=-=-=- drawOn: athensCanvas athensCanvas pathTransform restoreAfter: [ athensCanvas pathTransform scaleBy: rectangle extent asFloatPoint athensCanvas setPaint: color; drawShape: self path. (athensCanvas setStrokePaint: strokePaint) width: (self strokeWidth / self scale) asFloat. athensCanvas drawShape: self path ] -=-=-=-=- But with a different shapes, the border does not have same width all around the ellipse. See the image: Is there better way to draw it? Thank you, Jura -- Best regards, Igor Stasenko. inline: Captura de pantalla 2014-04-11 a la(s) 16.29.13.png
Re: [Pharo-users] Athens and ellipse drawing
On 12 April 2014 01:37, Juraj Kubelka juraj.kube...@gmail.com wrote: Thank you Igor, I suspect there is no better solution. But anyway I am surprised, every simple drawing application manages ellipses. Athens is not an application, it is framework. And why you think that every framework supports drawing ellipses as a basic command/primitive..for instance? I know of at least one, which doesn't - try drawing it with OpenGL. ;) Thank you anyway. Juraj El 11-04-2014, a las 17:35, Igor Stasenko siguc...@gmail.com escribió: yes, you using stroke for 2nd ellipse, but stroke width is also subject of scaling, that's why it has different width, because of non-uniform scaling (x/y). instead you can first, draw a filled ellipse (blue) and then draw green one over it. On 11 April 2014 21:33, Juraj Kubelka juraj.kube...@gmail.com wrote: Hi Igor, hi all! I am not sure how to properly draw ellipse. Right now I draw a path like this: The path is created that way: -=-=-=-=- computePath path := self athensCanvas createPath: [ :builder | builder absolute; moveTo: 0 @ 0.5; ccwArcTo: 0.5 @ 0.0 angle: 90 degreesToRadians; ccwArcTo: 0.0 @ -0.5 angle: 90 degreesToRadians; ccwArcTo: -0.5 @ 0.0 angle: 90 degreesToRadians; ccwArcTo: 0 @ 0.5 angle: 90 degreesToRadians ] -=-=-=-=- And draw it like this: -=-=-=-=- drawOn: athensCanvas athensCanvas pathTransform restoreAfter: [ athensCanvas pathTransform scaleBy: rectangle extent asFloatPoint athensCanvas setPaint: color; drawShape: self path. (athensCanvas setStrokePaint: strokePaint) width: (self strokeWidth / self scale) asFloat. athensCanvas drawShape: self path ] -=-=-=-=- But with a different shapes, the border does not have same width all around the ellipse. See the image: Captura de pantalla 2014-04-11 a la(s) 16.29.13.png Is there better way to draw it? Thank you, Jura -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.
Re: [Pharo-users] Socket Handles to C
On 9 April 2014 16:59, Sean P. DeNigris s...@clipperadams.com wrote:
How do Socket handles map to C socket IDs? I'm wrapping libssh2 via Native
Boost and I'd much rather create sockets via Smalltalk than C, but I'm not
sure how to pass the handle to a C function expecting a C socket ID. Maybe
I'm missing something really simple? Thanks.
socket plugin using own data structure for socket handles,
it includes different kind of internal information, including OS-specific
socket handle.
typedef struct
{
int sessionID;
int socketType; /* 0 = TCP, 1 = UDP */
void *privateSocketPtr;
} SQSocket, *SocketPtr;
extracting the OS-specific handle could be problematic, since it is in
that opaque void *privateSocketPtr; field.
Then:
sqUnixSocket.c
typedef struct privateSocketStruct
{
int s;/* Unix socket */
int connSema;/* connection io notification semaphore */
int readSema;/* read io notification semaphore */
int writeSema;/* write io notification semaphore */
int sockState;/* connection + data state */
int sockError;/* errno after socket error */
union sockaddr_any peer;/* default send/recv address for UDP */
socklen_t peerSize;/* dynamic sizeof(peer) */
union sockaddr_any sender;/* sender address for last UDP receive */
socklen_t senderSize;/* dynamic sizeof(sender) */
int multiListen;/* whether to listen for multiple connections */
int acceptedSock;/* a connection that has been accepted */
} privateSocketStruct;
so, to extract OS-level socked handle *on unix*, you have to
handle = ( (privateSocketStruct*) sqsocket.privateSocketPtr) - s.
where sqsocket is SQSocket.
there's even macros for that:
/*** Accessors for private socket members from a Squeak socket pointer ***/
#define _PSP(S)(((S)-privateSocketPtr))
#define PSP(S)((privateSocketStruct *)((S)-privateSocketPtr))
#define SOCKET(S)(PSP(S)-s)
#define SOCKETSTATE(S)(PSP(S)-sockState)
#define SOCKETERROR(S)(PSP(S)-sockError)
#define SOCKETPEER(S)(PSP(S)-peer)
#define SOCKETPEERSIZE(S)(PSP(S)-peerSize)
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/Socket-Handles-to-C-tp4753619.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
--
Best regards,
Igor Stasenko.
Re: [Pharo-users] [ANN] JNIPort for Pharo 3.0 alpha
: this will #become: the JNIObject into a global ref if necessary self convertToGlobal: aJNIObject. ^ super findClassFor: aJNIObject. -- so, without going deep into implementation details, just by reading comment i can already see potential bottleneck - using #become: operation which is veery slow. also, by tracking senders of #knownJavaSubclasses , i see there's also uses of #become operation.. So, my first verdict is: - excessive use of #become == slow performance :) (sure, i have no idea if you can avoid using become or not, but my bet this is main reason of low performance) -- Best regards, Igor Stasenko.
Re: [Pharo-users] I Can Read C++ and Java But I Can't Read Smalltalk
Your days, as scientist are counted, if you refuse to accept anything new.. same words, i think, can be applied to programming. On 30 March 2014 22:31, Esteban A. Maringolo emaring...@gmail.com wrote: When I first met Smalltalk, I found its syntax to be so disruptive to my mindset that made me want to learn it (I was coding Perl at that time). But not everybody feels the same. To some it is scary. Or unintelligible. It is true that many C like languages have hundreds of constructs, but it is also true that almost all the programmers know how to code in one of them, so then the knowledge mapping kicks in and those hundred of constructs reduce to a bunch of differences (something our brain is prepared to do very well). In the past one motto for smalltalk was talk small, and carry a big class library. Nowadays class library is the king, and we like or not, we smalltalkers just talk small. Though, I would not change Smalltalk's syntax for anything else. Regards! Esteban A. Maringolo 2014-03-30 16:24 GMT-03:00 Yuriy Tymchuk yuriy.tymc...@me.com: For me Smalltalk and Lisp are the easiest languages. In smalltalk everything is an object and in lisp everything is a list. And in other languages you have to learn 100500 language constructs and hacks. Uko On 30 Mar 2014, at 20:52, kilon alios kilon.al...@gmail.com wrote: Smalltalk is the easiest language I have learned so far. Python coming second and quite close. I also find Squeak by Example and Pharo by Example very good introductory guides. Smalltalk By Example is even better if you want to know more about the language. Smalltalk is similar to Lisp in the sense that it follows its own path and it takes some time to escape the C syntax. But overall Smalltalk and Lisp are excellent choices for beginner coders. The article you linked contains those peculiarities but those things will become apparent to anyone following Pharo by Example. And I dont think you will find many people arguing that C++ , Java are more readable than Smalltalk and Lisp. Sure to people that are not that experienced could be. But even in that case, I dont quite believe it. Overall however learning languages is not a big deal, its learning libraries that can become a real torture. For example I hated C++ because of MFC and I strongly disliked Java because of Swing. Now that I am learning Javascript , I dislike it because of DOM , Jquery etc . Also Its easy to find good documentation for languages much more difficult for libraries. So I am not buying that Smalltalk is anything else than very easy to learn. Other than that like any language out there it takes some time to get used to some things. On Sun, Mar 30, 2014 at 9:04 PM, Ben Coman b...@openinworld.com wrote: I came across this article a few days ago. Thought it might be of interest to some. http://www.eli.sdsu.edu/courses/spring01/cs635/readingSmalltalk.pdf -- Best regards, Igor Stasenko.
Re: [Pharo-users] How to draw a Morph with Athens?
u you u no draw morphs by athens :) - use AthensWrapMorph. put as many submorphs into it, and they all will be drawn via Athens. eventually, the need in wrap morph will disappear once WorldMorph (the root of all morphs) start using Athens directly. On 28 March 2014 18:53, MartinW w...@fastmail.fm wrote: At the moment i draw Morphs with Athens by copying how it is done in AthensDemoMorph: - adding a surface variable, - initializing an AthensCairoSurface, - getting an athens canvas by calling: surface drawDuring: [:canvas | ] - … Is there already a more straightforward possibility in the meantime? Also the way it is done in the AthensDemoMorph, when i save and quit an image with such a Morph open, there is a drawing error (red rectangle with yellow cross), once i restart the image. BTW, i really like drawing with Athens! M. -- View this message in context: http://forum.world.st/How-to-draw-a-Morph-with-Athens-tp4751463.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- Best regards, Igor Stasenko.
Re: [Pharo-users] Calculate angle between two vectors (probably @Igor :)
On 16 March 2014 17:01, MartinW w...@fastmail.fm wrote: Hello, i probably made some embarassing mistake, but as i cannot find it, i ask you to have a look at this method. It should calculate the angle between two vectors. And vectors are instances of Point (perhaps here is already a misconception?). It is used in my flocking simulation PharoBoids (http://smalltalkhub.com/#!/~MartinWalk/Boids) Here is my version of the method: angleBetween: vector1 and: vector2 onError: aBlock | cosinusOfAngle innerProductOfVectors productOfVectorsLengths| innerProductOfVectors := (vector1 dotProduct: vector2). productOfVectorsLengths := (vector1 r) * (vector2 r). productOfVectorsLengths = 0 ifTrue: [ ^ aBlock value ]. cosinusOfAngle := innerProductOfVectors / productOfVectorsLengths. ^ cosinusOfAngle arcCos But my Boids behave wrong when i use it. I found another implementation of the same problem by Igor Stasenko which works and looks like this: angleBetween: p1 and: p2 ifDegenerate: aBlock Calculate an angle (in radians) between two vectors. Evaluate a block, in case if calculation not possible because one of the vectors has zero length | x1 y1 x2 y2 dot2 n2 | x1 := p1 x. y1 := p1 y. x2 := p2 x. y2 := p2 y. dot2 := x1 * x2 + (y1 * y2). dot2 := dot2 * dot2. n2 := (x1*x1 + (y1*y1)) * (x2*x2 + (y2*y2)). n2 = 0 ifTrue: [ ^ aBlock value ]. ^ (dot2 / n2) arcCos Can anybody explain the problem of my method? M. yours looks correct. i'm just using squares to avoid taking square roots of vector lengths. -- View this message in context: http://forum.world.st/Calculate-angle-between-two-vectors-probably-Igor-tp4749351.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- Best regards, Igor Stasenko.
Re: [Pharo-users] Athens question - #openInSceneView
On 14 February 2014 15:57, J.F. Rick s...@je77.com wrote: Incomplete, though EllipseMorph would be quite easy to implement. You would have to implement drawOnAthensCanvas: on EllipseMorph. It is currently just inheriting that from Morph. Right. Cheers, Jeff On Wed, Feb 12, 2014 at 10:09 PM, Torsten Bergmann asta...@gmx.de wrote: If I understand correctly #openInSceneView wraps a morph in an Athens scene. I tried some examples: Smalltalk ui icons configIcon asMorph openInSceneView BorderedMorph new openInSceneView First two work, but the third: EllipseMorph new openInSceneView brought up a yellow morph - but as rectangle not as ellipse like in EllipseMorph new openInWorld. Havent looked deeper. Incomplete or a bug? Thx T. -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- Best regards, Igor Stasenko.
Re: [Pharo-users] [Pharo-dev] Nice chapter on NativeBoost
On 7 February 2014 21:41, Pharo4Stef pharo4s...@free.fr wrote: Hi guys today igor helped me to understand some hidden part of NativeBoost and we massively revisited and expanded the chapter started by L. Laffont this summer. Now you this is up to you to expand your knowledge :) It was really fun to get the X11 window resize and move :) https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccessfulBuild/artifact/NativeBoost/NativeBoost.pier.pdf https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccessfulBuild/artifact/NativeBoost/NativeBoost.pier.html Enjoy. Hehe, even i learned something today, that actually you can play with X11 even on Mac, because it has X11 support installed out of the box. (Btw, Stef you probably should mention that in chapter, especially details if you need to install something extra or not). Stef and Igor -- Best regards, Igor Stasenko.
Re: [Pharo-users] Drawing a line
On 16 January 2014 14:00, Маркіян Різун mri...@gmail.com wrote: Problem is solved) Looked at Canvas class and used it, as some of you adviced. it was me, me :) As for me it was the best choice for such a simple task. Thank you again. now you owe me a pony 2014/1/16 Маркіян Різун mri...@gmail.com Thanks for help. I'll try out your suggestions. Mark 16 січ. 2014 12:50, користувач Henrik Johansen henrik.s.johan...@veloxit.no написав: On 16 Jan 2014, at 10:52 , Маркіян Різун mri...@gmail.com wrote: Hello! Task is simple - draw a line on a form(actually this line will be a border of a cell). While browsing classes I found LineSegment and LineMorph. Which of them is better to use in my case? And another question: I know how to initialize both of them, but don't know how to draw it on my form. Thank you for help. Mark myForm getCanvas line: pt1 to: pt2 width: w color: c You only need to use a LineMorph if the line is not supposed to be static, otherwise drawing it directly on the Form is just as easy. Unless what you actually want is to create something like a spreadsheet, in which case a CellMorph, with RectangleMorph (cell outline) / StringMorph (cell contents) as subcomponents would probably be a better solution. (And the spreadsheet itself a morph, with CellMorphs as subcomponents) Cheers, Henry -- Best regards, Igor Stasenko.
Re: [Pharo-users] Pharo and the Morphic one window limitation
On 11 January 2014 14:39, kmo vox...@gmail.com wrote: i was just wondering whether there were any /definite/ plans to free Morphic from the one window restriction - apart from the obvious/ it will be done when someone gets the time/ inclination/ money to do it/? Is this something we can expect in Pharo 4.0 or 5.0 or 6.0? The current limitation is not a problem if your app uses a large window and all its other windows can fit easily inside it - but if you have a small application with a small main window (for example a minesweeper or soduku game) then you can't even fit in the load/save game dialog. I know I'm not saying anything new, but I was just wondering whether this was on a roadmap somewhere. yes. it is. and actively under development now. ken -- View this message in context: http://forum.world.st/Pharo-and-the-Morphic-one-window-limitation-tp4735921.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- Best regards, Igor Stasenko.
Re: [Pharo-users] Pharo and the Morphic one window limitation
On 11 January 2014 15:01, Esteban Lorenzano esteba...@gmail.com wrote: No, there are no official plans. There are plans to free pharo from the evil window initialization through vm, but no multiwindows support. But there are some no official plans to do it, and one of them is my own (Mars) which will allow you to dispatch morphs in separated windows, but is not usable (and it will not be for some time). yes, but morphic is not alpha and omega. once we will be able to free ourselves from 1 window 1 display slavery, it will open much more options. Esteban On 11 Jan 2014, at 14:39, kmo vox...@gmail.com wrote: i was just wondering whether there were any /definite/ plans to free Morphic from the one window restriction - apart from the obvious/ it will be done when someone gets the time/ inclination/ money to do it/? Is this something we can expect in Pharo 4.0 or 5.0 or 6.0? The current limitation is not a problem if your app uses a large window and all its other windows can fit easily inside it - but if you have a small application with a small main window (for example a minesweeper or soduku game) then you can't even fit in the load/save game dialog. I know I'm not saying anything new, but I was just wondering whether this was on a roadmap somewhere. ken -- View this message in context: http://forum.world.st/Pharo-and-the-Morphic-one-window-limitation-tp4735921.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- Best regards, Igor Stasenko.
Re: [Pharo-users] Athens on Pharo 3.0 on Ubuntu
On 6 January 2014 17:03, Bernat Romagosa tibabenfortlapala...@gmail.comwrote: Sorry guys, what a stupid mistake! Of course you can't call a 64b library, I hadn't thought about that... For Ubuntu x64 users, here's what you need to do: apt-get install libcairo2-dev:i386 amen :) 2014/1/6 Bernat Romagosa tibabenfortlapala...@gmail.com Hi list, I was just testing the new Pharo 3.0 on an Ubutu box, and I found the Athens Cairo examples are not working. The first bug is just about the path of libcairo.so.2 in Ubuntu x64, which is as follows: /usr/lib/x86_64-linux-gnu/libcairo.so.2 So, this path should be added to CairoLibraryLoader class pathToCairoOnLinux. Still, after adding it, I get: 'failed to get a symbol address: cairo_image_surface_create', and here I'm lost... any ideas what's going on? Thanks! -- Bernat Romagosa. -- Bernat Romagosa. -- Best regards, Igor Stasenko.
Re: [Pharo-users] NativeBoost: Regenerate Native Code
.. or just restart an image On 28 November 2013 12:01, Igor Stasenko siguc...@gmail.com wrote: On 27 November 2013 17:03, Sean P. DeNigris s...@clipperadams.com wrote: How do I tell NativeBoost to regenerate all naive code for a class e.g. after changing the implementation of #nbCallingConvention? N.B. to NativeBoost newbies like myself, this is a *huge* potential pitfall that's difficult to diagnose. I was thinking, well, I changed the calling convention and the vm is still crashing, so that can't be the problem not realizing that the callouts never picked up the change NativeBoost clearNativeCode - Cheers, Sean -- View this message in context: http://forum.world.st/NativeBoost-Regenerate-Native-Code-tp4725651.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.
Re: [Pharo-users] NativeBoost: Regenerate Native Code
On 27 November 2013 17:03, Sean P. DeNigris s...@clipperadams.com wrote: How do I tell NativeBoost to regenerate all naive code for a class e.g. after changing the implementation of #nbCallingConvention? N.B. to NativeBoost newbies like myself, this is a *huge* potential pitfall that's difficult to diagnose. I was thinking, well, I changed the calling convention and the vm is still crashing, so that can't be the problem not realizing that the callouts never picked up the change NativeBoost clearNativeCode - Cheers, Sean -- View this message in context: http://forum.world.st/NativeBoost-Regenerate-Native-Code-tp4725651.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- Best regards, Igor Stasenko.
Re: [Pharo-users] NativeBoost Questions while wrapping FMOD
On 25 November 2013 21:53, Sean P. DeNigris s...@clipperadams.com wrote:
Sean P. DeNigris wrote
I'm wrapping the FMOD cross-platform audio library
[snip]
I have a few more questions
Problem #1:
I have the following callout:
primitive: #primitiveNativeCall module: #NativeBoostPlugin
FMOD_RESULT FMOD_System_Init(
FMOD_SYSTEM *system,
int maxchannels,
FMOD_INITFLAGS flags,
void *extradriverdata);
^ self nbCall: #(FMOD_RESULT System_Init(NBExternalAddress system,
32, 0,
nil)).
It works fine on Mac. On Windows, it returns some crazy error code that is
not listed in the API.
However, if I wrap the FMOD DLL in another DLL that just forwards all
calls:
FMOD_RESULT System_Init(FMOD_SYSTEM *system, int maxchannels,
FMOD_INITFLAGS flags, void *extradriverdata)
{
return FMOD_System_Init(system, maxchannels, flags,
extradriverdata);
}
When I call out to the wrapper DLL, it works! Does that provide a clue as
to
what's going wrong when calling from NB?
This seems like a calling convention issue. By default, unless you specify,
NB using
cdecl calling convention, but on windows, many libs (especially kernel)
using stdcall convention.
Check how the library is built and which call convention it uses.
Or just try changing it and see if it solves the problem.
Other info:
- Other dll functions succeed, so there is communication with the library.
In fact, if I proceed past that first error, a sound starts to play... but
then the VM crashes...
Problem #2:
(much less important)
I wanted to be able to bundle the DLL with the image so one doesn't have to
copy it into the VM folder. If I use the full path for the wrapper DLL
described above, it is found, but when it calls fmodL.dll, which is in the
same directory, it can't be found. I could only get it to work if at least
fmodL.dll is in the VM plugins folder. Is there a way to specify more
search
locations for dynamic libraries from the image side?
No, you can do it yourself in a form of:
self nbCall: ... module: (self searchAndLoadLibrary)
Thanks!
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/NativeBoost-Questions-while-wrapping-FMOD-tp4724116p4725188.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
--
Best regards,
Igor Stasenko.
Re: [Pharo-users] NativeBoost Questions while wrapping FMOD
On 23 November 2013 09:07, Stéphane Ducasse stephane.duca...@inria.frwrote:
I really think that NativeBoost MUST HAVE a decent documentation.
i agree. i need to invest into it.
It is a central part of Pharo and Igor you should do something about it.
If I would know I would have written a chapter on it but I cannot because
I DO NOT KNOW.
Stef
On 21 November 2013 22:40, Sean P. DeNigris s...@clipperadams.com wrote:
I'm wrapping the FMOD cross-platform audio library. The code is MIT and
lives
at http://smalltalkhub.com/#!/~SeanDeNigris/FMOD
Problem #1:
I'm calling into the FMOD library with:
primStoreIsPlaying: channelHandle in: isPlayingHandle
primitive: #primitiveNativeCall module: #NativeBoostPlugin
FMOD_RESULT FMOD_Channel_IsPlaying(
FMOD_CHANNEL *channel,
bool *isplaying);
^ self nbCall: #(FMOD_RESULT
FMOD_Channel_IsPlaying(NBExternalAddress
channel, NBExternalAddress isPlayingHandle)).
I call the above with:
isPlaying
| isPlaying |
isPlaying := NBExternalAddress new.
self primStoreIsPlaying: channel in: isPlaying.
^ isPlaying value 0.
isPlaying is always 0. The method works directly from C with:
int isPlaying = 1;
while (isPlaying) {
FMOD_Channel_IsPlaying(channel, isPlaying);
}
I also tried changing the callout signature to ... bool*
isPlayingHandle)
and passing isPlaying := true. instead of using the NBExternalAddress
stuff.
err.. again, you must pass an address where value will be stored,
^ self nbCall: #(FMOD_RESULT FMOD_Channel_IsPlaying(
NBExternalAddress channel, NBExternalAddress * isPlayingHandle)).
otherwise you passing NULL pointer, and i quite surprised it not segfaults
when you call it like that (looks like they have a check in the library )
you can also use NBExternalTypeValue for that:
boolValueClass := NBExternalTypeValue ofType: 'bool'. sure thing,
creating anonymous class for each call is overkill, this should be done
once, somewhere else
boolValue := boolValueClass new.
self callTheThingWith: boolValue.
boolValue value ifTrue: [... blah]
(and this will work, assuming you have bool* in signature for this
argument).
I have a few more questions, but this is the most pressing as it's holding
up any further development.
Thanks!
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/NativeBoost-Questions-while-wrapping-FMOD-tp4724116.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
--
Best regards,
Igor Stasenko.
--
Best regards,
Igor Stasenko.
Re: [Pharo-users] NativeBoost Questions while wrapping FMOD
On 22 November 2013 05:09, Sean P. DeNigris s...@clipperadams.com wrote: Igor Stasenko wrote The better way is to subclass from NBExternalObject then which made exactly for such purposes, by holding an opaque handle to something (you don't care what is inside), and simplifies a lot of things. I made NBExternalObject subclass: #FMOD_SYSTEM. I then tried to use it via: system := FMOD_SYSTEM new. err := self System_CreateNBExternalObject: system. With callout: ^ self nbCall: #(FMOD_RESULT FMOD_System_Create(NBExternalObject system)). For the argument type in the signature, for good measure I tried: 1. NBExternalObject 2. FMOD_SYSTEM 3. NBExternalAddress All three with zero, one, and two *'s after. The only one that didn't report some variety of An instance of Xyz expected was FMOD_System_Create(FMOD_SYSTEM system) for which the library returns an invalid argument error code. yet again, you miss the right solution: you must pass a pointer to where value will be stored (since function doing exactly that). so you should do it like: 1. NBExternalObject subclass: #FMOD_SYSTEM. 2. method to call the function will look like following: create: system ^ self nbCall: #(FMOD_RESULT FMOD_System_Create(FMOD_SYSTEM * system)). 3. and call it like following: system := FMOD_SYSTEM new. self handleError: (self create: system) ifOk: [ ^ system ] 3a. optionally, you want want to initialize it just after you know that you obtained correct handle, to do that, you could do following: FMOD_SYSTEM classnew | system | system := super new. self handleError: (self create: system) ifOk: [ ^ self newWithHandle: system handle ] and newWithHandle: could look something like following: newWithHandle: aHandle system := super basicNew. system handle: aHandle. ^ system initialize (because it is important to set the handle first, like that you can actually initialize something more by using it, which you logically do, just after creating a new handle. and note you must not call 'super initialize' then, because it will reset handle.) and i'm sure you can find more elegant solution :) btw if anyone wants to play with it: 1. Gofer it smalltalkhubUser: 'SeanDeNigris' project: 'FMOD'; package: 'FMOD'; load. 2. Download the FMOD library for your platform: - windows - http://www.fmod.org/download/fmodstudio/api/Win/fmodstudioapi10208win-installer.exe - Mac - http://www.fmod.org/download/fmodstudio/api/Mac/fmodstudioapi10208mac-installer.dmg 3. Copy the library to FileLocator imageDirectory / 'FMOD Programmers API/api/lowlevel/lib/libfmod.dylib' The working example is: | sound | sound := FmodSound fromFile: '/path/to/file.mp3' asFileReference. [ sound play ] fork. The broken one described above is: FMOD exampleNBExternalObject. - Cheers, Sean -- View this message in context: http://forum.world.st/NativeBoost-Questions-while-wrapping-FMOD-tp4724116p4724192.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- Best regards, Igor Stasenko.
Re: [Pharo-users] NativeBoost Questions while wrapping FMOD
On 21 November 2013 22:40, Sean P. DeNigris s...@clipperadams.com wrote:
I'm wrapping the FMOD cross-platform audio library. The code is MIT and
lives
at http://smalltalkhub.com/#!/~SeanDeNigris/FMOD
Problem #1:
I'm calling into the FMOD library with:
primStoreIsPlaying: channelHandle in: isPlayingHandle
primitive: #primitiveNativeCall module: #NativeBoostPlugin
FMOD_RESULT FMOD_Channel_IsPlaying(
FMOD_CHANNEL *channel,
bool *isplaying);
^ self nbCall: #(FMOD_RESULT
FMOD_Channel_IsPlaying(NBExternalAddress
channel, NBExternalAddress isPlayingHandle)).
I call the above with:
isPlaying
| isPlaying |
isPlaying := NBExternalAddress new.
self primStoreIsPlaying: channel in: isPlaying.
^ isPlaying value 0.
isPlaying is always 0. The method works directly from C with:
int isPlaying = 1;
while (isPlaying) {
FMOD_Channel_IsPlaying(channel, isPlaying);
}
I also tried changing the callout signature to ... bool* isPlayingHandle)
and passing isPlaying := true. instead of using the NBExternalAddress
stuff.
err.. again, you must pass an address where value will be stored,
^ self nbCall: #(FMOD_RESULT FMOD_Channel_IsPlaying(
NBExternalAddress channel, NBExternalAddress * isPlayingHandle)).
otherwise you passing NULL pointer, and i quite surprised it not segfaults
when you call it like that (looks like they have a check in the library )
you can also use NBExternalTypeValue for that:
boolValueClass := NBExternalTypeValue ofType: 'bool'. sure thing, creating
anonymous class for each call is overkill, this should be done once,
somewhere else
boolValue := boolValueClass new.
self callTheThingWith: boolValue.
boolValue value ifTrue: [... blah]
(and this will work, assuming you have bool* in signature for this
argument).
I have a few more questions, but this is the most pressing as it's holding
up any further development.
Thanks!
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/NativeBoost-Questions-while-wrapping-FMOD-tp4724116.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
--
Best regards,
Igor Stasenko.
Re: [Pharo-users] Scaled PNG image
On 21 November 2013 21:27, Hilaire Fernandes hilaire.fernan...@gmail.comwrote: Le 21/11/2013 08:21, Stéphane Ducasse a écrit : On Nov 20, 2013, at 4:54 PM, Hilaire Fernandes hilaire.fernan...@gmail.com wrote: Hello, In Pharo 2.0 (true in 1.4 as well), it looks PNG bitmap are wrongly rotated or scaled when they contain alpha transparency. In the example bellow with the joined bitmap, the alpha gray color are rendered darker when the imagemorph is scaled or rotated. Sqeak does not suffer this problem hilaire may be you should have a look at the changes made in the graphics package I took at look on the list, did not find anything yet not directly, right. But since symptoms are similar, i think this is most probably the same case. (and your digging shown that we actually having separate rule for premultiplied alpha blend, which i could use for correctly transferring/blending cairo surface pixels in Forms) Hilaire of squeak to identify the change. We should have more tests. Stef | dir morph transform form| dir := FileSystem disk workingDirectory parent. morph := (ImageReadWriter formFromFileNamed: (dir / 'bubble.png') fullName) asMorph. transform := TransformationMorph new asFlexOf: morph. transform smoothingOn ; angle: Float pi / 3; scale: 1. transform openInWorld Thanks Hilaire -- Dr. Geo http://drgeo.eu bubble.png -- Dr. Geo http://drgeo.eu -- Best regards, Igor Stasenko.
Re: [Pharo-users] NativeBoost Questions while wrapping FMOD
On 22 November 2013 01:23, Sean P. DeNigris s...@clipperadams.com wrote: Igor Stasenko wrote err.. again, you must pass an address where value will be stored, hee hee... sorry... I don't understand enough of what's going on behind the scenes to adapt well. I reasoned that since last time, the signature was Whatever** and you said to make it NBExternalAddress*, that therefore Whatever* (one less *) would be NBExternalAddress (also one less *). While we're here, I'll ask my other questions... 1. What's the differenct between primitive: #primitiveNativeCall module: #NativeBoostPlugin and the variant with error:? What does the second one buy you? Historically, NB was first running on Squeak VM, which has no support for primitive error. Using extra #error: keyword in primitive is HIGHLY recommended, unless you want to deal with some quite rare (but possible and thus very hard to track down) wrong error reporting. 2. instead of returning useful objects, FMOD returns error codes and you pass a pointer to receive the object. - The first consequence is that I have to wrap all the calls e.g. self processErrorCode: self primCreate. where processErrorCode: anInteger anInteger = 0 ifFalse: [ self error: 'FMOD returned error code ', anInteger asString ]. Is there a more graceful way to do that? i doubt so.. since it is library API which dictates you to use it in certain way. The proper error handling never hurts (except from causing extra code bloat, of course :) - The second issue is how to create a Smalltalk object from the pointer. What I've been doing is: | soundHandle | soundHandle := NBExternalAddress new. self processErrorCode: (self primCreate: soundHandle on: system handle fromFile: file fullName). sound := FmodSystemSound on: soundHandle. Again, is there a better way? I thought to subclass NBExternalAddress, but evaluating sound := FmodSystemSound new to pass to the callout seemed a bit dirty i.e. it is not a invalid instance until initialized by the callout. I also played around with NBExternalObject, but couldn't get that to work either... The better way is to subclass from NBExternalObject then which made exactly for such purposes, by holding an opaque handle to something (you don't care what is inside), and simplifies a lot of things. Thanks for all the support. This is fun!! You are very welcome. - Cheers, Sean -- View this message in context: http://forum.world.st/NativeBoost-Questions-while-wrapping-FMOD-tp4724116p4724158.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- Best regards, Igor Stasenko.
Re: [Pharo-users] optimizing io
On 20 November 2013 13:40, Esteban A. Maringolo emaring...@gmail.comwrote: If your sockets are connection oriented (it is. TCP) using IP Multicast won't be an option. Multicast was made with Datagrams in mind instead of Packets. Though there was a multicast solution that numbered the datagrams to request retransmission in case of packet loss. Yeah, but that's what you probably should do to avoid duplicating traffic in a first place: use proper technology for that. Regards, Esteban A. Maringolo 2013/11/20 Santiago Bragagnolo santiagobragagn...@gmail.com: Great info! Thanks! 2013/11/20 Igor Stasenko siguc...@gmail.com Dig deeper: IP protocol supports broadcasting/multicasting. http://en.wikipedia.org/wiki/IP_multicast On 20 November 2013 08:49, Santiago Bragagnolo santiagobragagn...@gmail.com wrote: Hi all! Im making some performance enhancement on PhaROS, i realised that one of my common scenarios is having several sockets that should receive exactly the same information, in order to do that, im using n calls to the vm, which does n system-calls. I was wondering if there something done in: - send the same data to all the sockets in just one primitive - send the same data to all the sockets in just one syscall. I checked around in google but i didn't found anything useful, but probably i have no knowledge about the proper words for such search :). Thanks! -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.
Re: [Pharo-users] NBOpenGL on Pharo 3.0
:) 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 \ yes, my bad. 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 tu...@tudorgirba.comwrote: 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.duca...@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. Best Regards Jean Baptiste Arnaud jbaptiste.arn...@gmail.com Best Regards Jean Baptiste Arnaud jbaptiste.arn...@gmail.com Best Regards Jean Baptiste Arnaud jbaptiste.arn...@gmail.com -- www.tudorgirba.com Every thing has its own flow Best Regards Jean Baptiste Arnaud jbaptiste.arn...@gmail.com -- Best regards, Igor Stasenko.
Re: [Pharo-users] CogVM arguments in Win32
On 13 November 2013 10:25, Bernat Romagosa
tibabenfortlapala...@gmail.comwrote:
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
MSDNhttp://msdn.microsoft.com/en-us/library/windows/desktop/bb762159(v=vs.85).aspx
:
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
formhttp://msdn.microsoft.com/en-us/library/windows/desktop/bb773352(v=vs.85).aspx
:
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 tibabenfortlapala...@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 p...@highoctane.be p...@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 siguc...@gmail.comwrote:
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
tibabenfortlapala...@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
MSDNhttp://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
Re: [Pharo-users] NBOpenGL on Pharo 3.0
On 13 November 2013 11:32, Stéphane Ducasse stephane.duca...@inria.frwrote: 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 tu...@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.duca...@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.
Re: [Pharo-users] CogVM arguments in Win32
On 13 November 2013 12:02, Bernat Romagosa tibabenfortlapala...@gmail.comwrote: 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 asta...@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 WinConsoleConstantsinitTypeConstants, 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.
Re: [Pharo-users] Why won't my Pharo download run?
On 7 November 2013 14:18, PBK Research pe...@pbkresearch.co.uk wrote: Hello! I have a problem with running Pharo 2.0 on one of my machines. I have two machines, both running Windows XP with SP3. On one of them I have a successful load of Pharo (actually it's a distribution of the Moose system, but that is just an application built on Pharo 2.0). This loads successfully when I double click on pharo.exe. On the other machine, the same action produces an immediate message: 'Pharo.exe has encountered a problem and needs to close'. Just in case this was some problem with Moose, I have just downloaded the latest one-click installation of Pharo 2.0 for Windows. This displays exactly the same behaviour - an immediate fail when I try to start it. I have tried to work out what may be different between the two machines. The one which will run Pharo has an Intel Celeron processor, the other an AMD Athlon XP (yes, they are both pretty ancient!), but I can't see why that should make any difference. The one curious thing is that Windows Explorer displays the type of the Pharo2.0.image file as 'Squeak image file'. There is an old version of Squeak installed on that machine; could that have any effect? I am a bit flummoxed by all this. Does anyone have any suggestions about how to diagnose the problem? If you using too old VM , it simply does not supports an image format, which pharo 2.0 uses. But there could be different reasons.. a first step towards to solution is to use VM for pharo, which we maintain and use.. Many thanks Peter Kenny -- Best regards, Igor Stasenko.
Re: [Pharo-users] Why won't my Pharo download run?
On 7 November 2013 15:31, PBK Research pe...@pbkresearch.co.uk wrote: Thanks. I am using the latest one-click distribution of Pharo, downloaded today from the Pharo website. Presumably that should have the latest VM? yes, but if .image file extension associated with wrong version of VM binary, which you installed previously (as you mentioned), it won't automagically use proper one. unless you run vm from command line e.g.: pharo.exe myimage.image or change the association to use different vm. -- *From:* Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] *On Behalf Of *Igor Stasenko *Sent:* 07 November 2013 13:53 *To:* Any question about pharo is welcome *Subject:* Re: [Pharo-users] Why won't my Pharo download run? On 7 November 2013 14:18, PBK Research pe...@pbkresearch.co.uk wrote: Hello! I have a problem with running Pharo 2.0 on one of my machines. I have two machines, both running Windows XP with SP3. On one of them I have a successful load of Pharo (actually it's a distribution of the Moose system, but that is just an application built on Pharo 2.0). This loads successfully when I double click on pharo.exe. On the other machine, the same action produces an immediate message: 'Pharo.exe has encountered a problem and needs to close'. Just in case this was some problem with Moose, I have just downloaded the latest one-click installation of Pharo 2.0 for Windows. This displays exactly the same behaviour - an immediate fail when I try to start it. I have tried to work out what may be different between the two machines. The one which will run Pharo has an Intel Celeron processor, the other an AMD Athlon XP (yes, they are both pretty ancient!), but I can't see why that should make any difference. The one curious thing is that Windows Explorer displays the type of the Pharo2.0.image file as 'Squeak image file'. There is an old version of Squeak installed on that machine; could that have any effect? I am a bit flummoxed by all this. Does anyone have any suggestions about how to diagnose the problem? If you using too old VM , it simply does not supports an image format, which pharo 2.0 uses. But there could be different reasons.. a first step towards to solution is to use VM for pharo, which we maintain and use.. Many thanks Peter Kenny -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.
Re: [Pharo-users] Why won't my Pharo download run?
Well, it could be that your machine CPU too old and don't supports instructions (like SSE) which VM compiled with. On 7 November 2013 19:44, PBK Research pe...@pbkresearch.co.uk wrote: Just a little more information. Out of curiosity, I downloaded Pharo 3.0 and tried it, with the same result - message from Windows says 'Pharo.exe has encountered a problem and needs to close'. To complete the set, I downloaded Pharo 1.4 and tried it. This time it failed saying 'CogVM.exe has encoun'. I presume all versions now use the Cog VM, and it looks as though this machine just won't run it. Is there still a 'traditional' VM I can use instead of Cog? It might not be practical, but it would at least prove that it is a VM problem. Is there any information about Cog giving problems with AMD processors? -- *From:* Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] *On Behalf Of *PBK Research *Sent:* 07 November 2013 15:07 *To:* 'Any question about pharo is welcome' *Subject:* Re: [Pharo-users] Why won't my Pharo download run? OK. I opened a command line prompt, cd to Pharo 2.0 directory (created in today's download), enter 'pharo.exe pharo2.0.image'. Same result - immediate failure. I had previously changed the association of the image file to the newly downloaded pharo.exe. So I think I must be using the VM in today's download. -- *From:* Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] *On Behalf Of *Igor Stasenko *Sent:* 07 November 2013 14:48 *To:* Any question about pharo is welcome *Subject:* Re: [Pharo-users] Why won't my Pharo download run? On 7 November 2013 15:31, PBK Research pe...@pbkresearch.co.uk wrote: Thanks. I am using the latest one-click distribution of Pharo, downloaded today from the Pharo website. Presumably that should have the latest VM? yes, but if .image file extension associated with wrong version of VM binary, which you installed previously (as you mentioned), it won't automagically use proper one. unless you run vm from command line e.g.: pharo.exe myimage.image or change the association to use different vm. -- *From:* Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] *On Behalf Of *Igor Stasenko *Sent:* 07 November 2013 13:53 *To:* Any question about pharo is welcome *Subject:* Re: [Pharo-users] Why won't my Pharo download run? On 7 November 2013 14:18, PBK Research pe...@pbkresearch.co.uk wrote: Hello! I have a problem with running Pharo 2.0 on one of my machines. I have two machines, both running Windows XP with SP3. On one of them I have a successful load of Pharo (actually it's a distribution of the Moose system, but that is just an application built on Pharo 2.0). This loads successfully when I double click on pharo.exe. On the other machine, the same action produces an immediate message: 'Pharo.exe has encountered a problem and needs to close'. Just in case this was some problem with Moose, I have just downloaded the latest one-click installation of Pharo 2.0 for Windows. This displays exactly the same behaviour - an immediate fail when I try to start it. I have tried to work out what may be different between the two machines. The one which will run Pharo has an Intel Celeron processor, the other an AMD Athlon XP (yes, they are both pretty ancient!), but I can't see why that should make any difference. The one curious thing is that Windows Explorer displays the type of the Pharo2.0.image file as 'Squeak image file'. There is an old version of Squeak installed on that machine; could that have any effect? I am a bit flummoxed by all this. Does anyone have any suggestions about how to diagnose the problem? If you using too old VM , it simply does not supports an image format, which pharo 2.0 uses. But there could be different reasons.. a first step towards to solution is to use VM for pharo, which we maintain and use.. Many thanks Peter Kenny -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko.
Re: [Pharo-users] CogVM arguments in Win32
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 tibabenfortlapala...@gmail.comwrote: 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 MSDNhttp://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.
Re: [Pharo-users] another talk online: Pharo: Objects At Your Fingertips
On 31 October 2013 10:30, Sven Van Caekenberghe s...@stfx.eu wrote: Beautiful and useful ! except that video is in Silvercensored format, not avail on macos. :( Is there a copy with more open encoding (like mp4/mpeg?) On 31 Oct 2013, at 10:08, Marcus Denker marcus.den...@inria.fr wrote: The idea of this talk is to give an intro for someone who know OO but not Pharo (or Smalltalk). (this means for someone who does it has noting new) Pharo: Objects At Your Fingertips A talk given at Universitat Politècnica de Catalunya on Oct 30, 2013. SlideShare: http://www.slideshare.net/MarcusDenker/pharo-objects-at-your-fingertips PDF: http://marcusdenker.de/talks/13BarcelonaTalk/PharoObjectsAtYourFingertips.pdf Video: http://media.fib.upc.edu/fibtv/streamingmedia/view/2/821 -- Best regards, Igor Stasenko.
