[Pharo-project] ODBC schema acess - please test
see OdbcConnectiontables, #columnsForTable:owner:, #serverName, etc. DolphinCompatibility-ODBC-BillSchwab.1.mcz Description: DolphinCompatibility-ODBC-BillSchwab.1.mcz
[Pharo-project] Config browser
Just getting to 1.4 summer (apologies to those down under) and noted a long list of configs that seem to load cleanly - huge progress!!
Re: [Pharo-project] Differential and Integral calculus in Pharo?
short of symbolic manipulation (e.g. maple), all we do is discretize and approximate, right? Integration (aka quadrature) is easy but numerical diff is very unstable. ODEs solve well w/ Runge-Kutta methods. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of David Shaffer [cdshaf...@acm.org] Sent: Sunday, August 05, 2012 5:13 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Differential and Integral calculus in Pharo? On Aug 1, 2012, at 6:03 PM, Clara Allende wrote: Hi guys, after having exhausting four months of Physics lessons, I decided that would be fun to write a program to deal with Electricity problems :) (Yeah, I'm not a normal person :P) So, I need to make differential and integral calculus, are there any libraries to do so? Or any place that I can take a look at? Thanks in advance! Cheers In case you haven't already come across it: http://sourceforge.net/projects/dhbnumerics/ In my personal experience the algorithms in the book are often naive and problematic compared to industrial-strength numerical algorithms but they are also quite often good enough for a first attempt at some numerical work. David
Re: [Pharo-project] **IMPORTANT** MUST READ: Pharo Association and Consortium
Stef, I'll be good for at least 40, maybe 99. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [s...@clipperadams.com] Sent: Saturday, June 30, 2012 8:48 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] **IMPORTANT** MUST READ: Pharo Association and Consortium I will be a personal golden member (99EUR/year). It's very exciting to have this opportunity to sustain the great work of Igor, Esteban, et al. One thing I've been wondering is how contributors fit into the structure... it seems that members of our community spending many hours creating new features, fixing bugs, etc. should be formally recognized and have input into the direction of Pharo. Sean -- View this message in context: http://forum.world.st/IMPORTANT-MUST-READ-Pharo-Association-and-Consortium-tp4637096p4637597.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Do the VM's used on Jenkins include the SSL plugin ?
+20 :) From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguc...@gmail.com] Sent: Wednesday, June 27, 2012 4:48 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Do the VM's used on Jenkins include the SSL plugin ? We should really shift the paradigm of assuming that plugins is there towards having a nice error handling/presenting the reason why it fails, like in this case it should try and detect that plugin is not found/cannot be loaded and produce correct error message instead of very informal primitive failed message :)
Re: [Pharo-project] VM , modules, packages and plugins
I agree, except for silent updates. One should at know what is happening, and further be able to run a broken mixture, if only for debugging. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguc...@gmail.com] Sent: Wednesday, June 27, 2012 6:48 PM To: Pharo Development Subject: [Pharo-project] VM , modules, packages and plugins Seeing another thread about is XYZ plugin there or not or what may cause prim fail i REALLY suggest that we should stop and think.. This plugin's usage logic is inherently flawed.. (or i would say outdated) What i would like to see one day is when i installing new code into image, it pops up a message: Your VM missing an XYZ plugin for running this cool code, would you like to download and install it? Yes No In case of Pharo, we should really start thinking about delivering quality grade solutions, not something which might work if you properly jump 2 times and whistle 7 times while faced North... Look at what the practices which become common today in modern browsers, and OSes - they updating themselves without a notice and just asking you to restart it time to time. Why we cannot do the same? -- Best regards, Igor Stasenko.
Re: [Pharo-project] Pharo and Namespaces
+1 on not adding syntax. Never do to a language that which can be done with the language. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of James Foster [smallt...@jgfoster.net] Sent: Tuesday, June 26, 2012 3:30 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo and Namespaces On Jun 26, 2012, at 11:19 AM, Stéphane Ducasse wrote: What happened to the project from Germán Leiva http://www.youtube.com/watch?v=n4I7fSVNX2A we do not want class level namespace because this is the mess As the sponsor for Germán's project, I have some interest in this topic. Stéphane has said a couple times that it is wrong but has never taken time to explain his objections. We do not want to have class name resolution at the granularity of a class. And are you saying this because you think Germán's implementation does this? Why because it means that in the same package reading the code containing a class Foo could be a different one. I don't understand your example. I don't know what you mean by package reading the code. Are you describing a package that defines classes Foo and Bar, and a method in a class Bar that references the Foo in the same package? Are you providing this example because you think Germán's implementation does not support this use case? I'm saying that since years. I agree you have been saying that Germán's implementation isn't what you want. I just don't understand what you don't like about it. Name resolution of all variables (including Globals, of which Classes are a subset) should be part of a method compile. At the time a method is compiled, an 'environment' should be provided to the compiler that indicates how global name resolution should occur. This is a tools issue and it should be possible to specify the default namespace environment for the method, for a method category, for a class, for a class category, for a package, and for the system as a whole. In addition, within a particular method it should be possible to explicitly reference a particular namespace environment, whether through syntax (dot or double colons) or through message sends (e.g., a Dictionary's #'at:' method). I prefer not to add new syntax and favor GemStone's implementation over that of VisualWorks. If you don't have time to discuss this in depth I would be less frustrated if you would wait to say it is wrong until you have time to explain why. James Foster
Re: [Pharo-project] Zinc intermittently returning nil
I know *nothing* about Zinc, but my first thought is weak collections and how they are not thread safe (which they need to be) and are not self-repairing after finalization - they end up w/ retained nils. Dolphin blazed the correct trail on this in the mid to late 90s. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [s...@clipperadams.com] Sent: Tuesday, June 26, 2012 11:33 PM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Zinc intermittently returning nil The following all intermittently return nil. When I do the same thing in Safari, I always seem to get the correct answer (plain text). (ZnEasy get: 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=%2F%2A%2Fdescription%2Ftext%28%29') contents. (ZnClient new get: 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=%2F%2A%2Fdescription%2Ftext%28%29') contents. (ZnUrl fromString: 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=%2F%2A%2Fdescription%2Ftext%28%29') retrieveContents. Even this returns nil intermittently (maybe less frequently, not sure): client := ZnClient new. client systemPolicy; url: 'https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=%2F%2A%2Fdescription%2Ftext%28%29'; accept: ZnMimeType textPlain. client get contents. Sean -- View this message in context: http://forum.world.st/Zinc-intermittently-returning-nil-tp4636820.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Code completion in all tools
Have a look at codeCompletionAround: textMorph:keyStroke: HTH, Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [s...@clipperadams.com] Sent: Friday, June 22, 2012 2:22 PM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Code completion in all tools Issue 6135: Code completion in all tools http://code.google.com/p/pharo/issues/detail?id=6135 Pharo2.0a Latest update: #20156 Why don't we have code completion in e.g. the inspector/explorer? Would it be hard to implement? I took a look at Workspace, but I couldn't find where completion gets set up... Cheers, Sean b.t.w. less important, the syntax highlighting for the inspector is for a method pane (i.e. bold first line, etc) http://code.google.com/p/pharo/issues/detail?id=6136 -- View this message in context: http://forum.world.st/Code-completion-in-all-tools-tp4636201.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] New System Progress Bar
Events are preferable to exceptions for updating the bar. Exceptions should be reserved for things that are exceptional :) Event registrations should be weak so that one *can* set and forget, but one should also be able to explicitly unregister if desired/needed. I will also take this opportunity to re-assert that weak collections should be inherently thread-safe and self-repairing. Pharo's weaklings do not measure up to Dolphin's in these areas. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [s...@clipperadams.com] Sent: Thursday, June 21, 2012 10:14 AM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] New System Progress Bar To help explain the changes, here's a snippet from the fix to Issue 6099: Deprecate #value: for system progress (was red cross during updates) (http://code.google.com/p/pharo/issues/detail?id=6099). The API (see SystemProgressItemMorph) is not set in stone, but it's already much less confusing than the old pseudo-class implementation. Ultimately, I'd like to move to announcements instead of exceptions to signal progress, and decouple the progress model/view - maybe just [un]registering the progress morph to enable/disable. The slice in the inbox for this issue should fix the red cross during updates problem... MOTIVATION: The old system progress worked like this (for example)... SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar | 1 to: 100 do: [ :x | bar value: x. bar value: 'On iteration ', x asString. (Delay forMilliseconds: 20) wait Just to slow it down so we can see what's going on ] ]. * The work block ([ :bar | ... ] above) would accept one argument * That argument (:bar above) would be a block, that would act as a pseudo-class. Depending on what was passed to #value:, it would perform different functions. Two are illustrated above: - #value: aNumber; where aNumber is between the min and max of the progress range - Set the bar's current progress mark to that position. For example, 'bar value: 50' above would show the operation half complete - #value: aString - Set the label of the progress morph to aString This was very confusing, so we created a real class, SystemProgressItemMorph, which now gets passed to the work block, and has a real API. So, for example, the following becomes: SystemProgressMorph show: 'Doing...' from: 1 to: 100 during: [ :bar | 1 to: 100 do: [ :x | bar current: x. bar label: 'On iteration ', x asString. (Delay forMilliseconds: 20) wait Just to slow it down so we can see what's going on ] ]. As you can see, '#value: newValue' has become '#current: newValue', and '#value: newLabel' has become '#label: newLabel'. One wrinkle is that some users were passing a nil-like block instead of the the pseudo-class to suppress the system progress bar. For example: informUserDuring: aBlock aBlock value: [:string | ]. Above, [:string | ] would now cause a DNU when sent, for example, #current:, which obviously blocks don't understand. So, these cases were changed like so: informUserDuring: aBlock aBlock value: DummySystemProgressItem new. Where DummySystemProgressItem simply ignores all messages without signaling an error -- View this message in context: http://forum.world.st/New-System-Progress-Bar-tp4635912.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] start thinking on summer release of Pharo 1.4
+1 From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguc...@gmail.com] Sent: Sunday, June 17, 2012 6:48 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 i for Pharo 1.4.1 no messy naming please. Let's care more about what we put under the hood, than on glossy cover. -- Best regards, Igor Stasenko.
Re: [Pharo-project] start thinking on summer release of Pharo 1.4
I have been a vocal critic of configs, largely on grounds of excessive complexity, but I find your message a bit harsh. Long delays and hangs are BAD, but that can be addressed using background threads. This is a prime example of why say that sockets should never block the entire image (only calling thread) and should not have anything to say about timeouts - the latter are an app programming/user decision. The list of configs appearing in the browser is encouraging. I'd hope to see ODBC listed too, but Glorp is there. If all of these configs offer and can load a #stable version, that would be huge progress. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of p...@highoctane.be [p...@highoctane.be] Sent: Sunday, June 17, 2012 6:44 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 Who is his/her right mind would be able to make sense of this without a lot of preexposure? And who the hell are those people? And figuring out they need to right click, followed by a load configuration *and* stable version? Followed by a lng wait. And if there is no internet, well, it would freeze for a significant while. That's the feedback I get from people I try to get into the flow. Lots of blank stares... along the lines of What the heck are you doing? Phil 2012/6/17 Esteban Lorenzano esteba...@gmail.com: On Jun 17, 2012, at 5:10 AM, Ben Coman wrote: Is Nautilus under any consideration to be the default browser for your summer release at all, or are you firmly committed to OB? I need to know this to continue updating Pharo By Example for 1.4. this is an interesting and important issue (much more than codenames, he). I will extend my latest answer, using what I know (maybe Benjamin has another idea, and would be good to know it): Nautilus is in development, there are some important functionalities that are not there yet, and some others that does not work properly. Refactors and Traits is the most important things I can think of now, but there are probably more. Also, Nautilus relies in RPackage, which was not ready for 1.4 (but will be ready for 2.0). And some other packages (like OB itself) can be not-loadable after installing Nautilus. To make all of this work in 1.4 can be a huge job (at least for RPackage, it is, I don't know for Nautilus). I know that RPackage cannot be backported without a lot of effort, but I don't know if Nautilus for 1.4 can be adapted to not use RPackage easily (which AFAIK, should be necessary to make it work propertly). So, I will like your work (which is IMO terribly important) would take Nautilus. But I also think that loading it for default in 1.4 is probably too much. Frankly, I don't know what to do now :) Esteban -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: p...@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
Re: [Pharo-project] Jenkins down?
Looks that way from here (Florida). From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of p...@highoctane.be [p...@highoctane.be] Sent: Sunday, June 17, 2012 3:49 PM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Jenkins down? -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: p...@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
Re: [Pharo-project] start thinking on summer release of Pharo 1.4
Stef, I have had experts on it tell me exactly the opposite. Things like always load specific versions and never load symbolic versions. They mean well (and have been helpful in the short term), but it is far from a generic solution. The answer will invariably be different every time. Citezen is much appreciated, but your answer to getting it to load was to load a specific numeric version. Ditto Alien/FFI from others. I am simply repeating what I have been told. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Saturday, June 16, 2012 4:24 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 On Jun 16, 2012, at 12:57 AM, Schwab,Wilhelm K wrote: But if I'm building a new image *today*, I want it to do the right thing now (automatically for the current version), with the same incantation as worked months ago or months from now. Bill when do you take the time to have a look at Metacello. Why people like me are spending days on writing 45 pages of documentation to hear you saying that. This scenario is supported since months nearly since Barcelona 2010. If we can't do that, the config browser is pretty much a dream vs. reality. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [s...@clipperadams.com] Sent: Friday, June 15, 2012 2:49 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 Schwab,Wilhelm K wrote My gripe is... that configs... work (very) differently over time With the current evolution of Metacello, this should not be the case. Done right, what a config loads can be 100% static and repeatable. If you load a literal version (e.g. '1.4'), which loads literal versions of dependent projects (which they should unless there is a reason not to, e.g. a loose dependency like Seaside on OB), which load literal versions all the way down, it will do the same thing today, tomorrow, and ten years from now. The only hill to climb now is getting the word out about Metacello conventions/best practices. Schwab,Wilhelm K wrote If pre-loading, how about FFI? I think easily loadable is the correct state, not included by default. -- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp4634589p4635009.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] start thinking on summer release of Pharo 1.4
If it helps at all, I was able (with help) to get sound working on Linux. It's ugly: one has to copy/rename the plugin from another vm (to use cog). Once I got it working, I flagged a copy of the plugin in the hopes of making things easier next time. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Esteban Lorenzano [esteba...@gmail.com] Sent: Saturday, June 16, 2012 6:20 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 Hi, you are asking for two things there: -a sound package for pharo 1.4 (I don't know if it exists, and in any case we cannot add it as a core package, you need to install it and see how it works by yourself) -a working sound plugin for iOS. TBH, while I'm including it in regular compilations, I never tested it, so I don't know if is working properly. Of course, to do games and others, is clear that we need a working sound system into iOS... . Esteban On Jun 15, 2012, at 11:36 PM, p...@highoctane.be wrote: Well, spotlight is really cool indeed. Shift-Space XXX Enter. yay! But I like to have a view on several classes and typing HOPR¨helps. Same when exploring the system for doing something (like sound-synthesis for example). BTW, any new stuff on the MP3 front? I am looking at the sophie 1.0 extract of yours. As of Pharo 1.4 Summer Release, having a somewhat cleaned up Sound-synthesis in it would be nice. I am currently creating a little game in Smalltalk targeting the iPad and a game without sound is not that of a game. For beginners and motivating people to move aboard the platform, sound is important to have. KR Philippe 2012/6/15 Sean P. DeNigris s...@clipperadams.com: philippeback wrote Have been using Nautilus and OB and albeit Nautilus is nicer looking, I find my way better with OB. Especially with the top search bar and categorizing into protocols. More buttons under the lists in OB but I do prefer them actually. Overall, I like Nautilus' workflow better, but I know what you mean about the buttons. Even with the visual feedback, I'm never quite sure if I'm in class-side mode, or I have to hit the button to get class-side mode. I was missing the search bar, but with spotlight, it's moot. Sean -- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp4634589p4635007.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: p...@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
Re: [Pharo-project] start thinking on summer release of Pharo 1.4
But if I'm building a new image *today*, I want it to do the right thing now (automatically for the current version), with the same incantation as worked months ago or months from now. If we can't do that, the config browser is pretty much a dream vs. reality. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [s...@clipperadams.com] Sent: Friday, June 15, 2012 2:49 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 Schwab,Wilhelm K wrote My gripe is... that configs... work (very) differently over time With the current evolution of Metacello, this should not be the case. Done right, what a config loads can be 100% static and repeatable. If you load a literal version (e.g. '1.4'), which loads literal versions of dependent projects (which they should unless there is a reason not to, e.g. a loose dependency like Seaside on OB), which load literal versions all the way down, it will do the same thing today, tomorrow, and ten years from now. The only hill to climb now is getting the word out about Metacello conventions/best practices. Schwab,Wilhelm K wrote If pre-loading, how about FFI? I think easily loadable is the correct state, not included by default. -- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp4634589p4635009.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] start thinking on summer release of Pharo 1.4
Digging through my so-called memoryg, loading both Alien and Citezen required special attention. Alien led to a broken image, and Citezen was simply tricky to load such that it would work. Both required requesting specific versions in order to work. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [s...@clipperadams.com] Sent: Friday, June 15, 2012 8:08 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 Schwab,Wilhelm K wrote But if I'm building a new image *today*, I want it to do the right thing now (automatically for the current version), with the same incantation as worked months ago or months from now. Absolutely! Two things about that: * Metacello has no magic. Ultimately, what you correctly suggest requires someone to test a project on a new platform and update the config... coming soon and desperately needed: tools to help this process... * we're all learning how to use Metacello... even as it evolves underneath us! If you experience something other than above, please post the specific example so we can examine the configs and see what's going on... -- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp4634589p4635050.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] start thinking on summer release of Pharo 1.4
My gripe is not so much that configs don't work together, it's that they work (very) differently over time; the work I did last week to build an image could be (often is) worthless today. Configs really need to reflect on versions and do the right thing vs. current complexity. If pre-loading, how about FFI? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of p...@highoctane.be [p...@highoctane.be] Sent: Wednesday, June 13, 2012 6:23 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] start thinking on summer release of Pharo 1.4 Esteban, Definitely worth doing!!! Install all the stuff I need on new images etc just to the have to discard them for some reason doesn't makes me reinstall anything afterwards. Tried to work the way of Mariano with the ConfigurationOf but frankly, let it fall by the wayside. Just too many problems with loading packages that do work well together etc. And no refactoring out of the box in 1.4 is really lame indeed. As for Nautilus in 2.0, the regular yellow crosses on red background are getting on my nerves, especially since I don't know why they do appear.$ So, yeah: +1 Philippe 2012/6/13 Esteban Lorenzano esteba...@gmail.com: Hi, I started thinking on next release of Pharo 1.4 (which will be code named summer, not an ugly number). I've been monitoring the list and I think there are some things to improve, so I'm planning to add this things to new one click: - pre-load OmniBrowser. Why I'm suggesting this? Because nobody seems to notice that OB is actually working on 1.4 and everybody complains that you cannot have refactors, blabla, which is just not true, but is causing a lot of bad feeling around what is a great release (yes, I'm making some constructive criticism about the list attitude, but also about our/mine communicational capabilities). Original idea was to allow people to choose OB or Nautilus, since the last one will be the browser for Pharo in the future, but truth is that Nautilus is still a technology preview... and it will be there for all those like me, who want to use it. Finally, most important issue is that newcomers expect to have a full environment working out of the box, and they don'y know how to use the Configuration Browser. - pre-load Spotlight Yeah, another small tool who can make your life easy. Why? just because I'm tired of seeing all of you typing class names at workspace and press cmd+b later... or using some more uncomfortable ways to reach your code. If you still prefer those ways, is up to you ;) So far, this and the bugfixes we already made (and some more)... What do you think? Esteban -- Philippe Back Dramatic Performance Improvments Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: p...@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges Belgium
[Pharo-project] 2.0
I grabbed the one-click image and poked around. The worst thing I found (can't reproduce) is that the SB's package list became insensitive to clicks. Switching to groups and then back seemed to restore normal operation. Looks good so far! Bill
Re: [Pharo-project] FileReference should throw error when deleting unexisting files?
I generally default to saying of course there should be an error. I much prefer to get my bad news early rather than having to fish around or it after the fact. Toward that end, I would recommend having #deleteIfAbsent: and #delete that provides an error-raising block and forwards to #deleteifAbsent:. That is consistent with collections, which are not a bad model/source-of-inspiration for managing directory contents. Having #ensureDeleted in addition to above does no real harm. I would prefer that the selector start with delete so it appears close to the other methods in browsers, even w/o category filtering - makes it more discoverable. Just my 2 asCents. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Chris Cunningham [cunningham...@gmail.com] Sent: Monday, June 11, 2012 5:55 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FileReference should throw error when deleting unexisting files? On Mon, Jun 11, 2012 at 2:32 PM, petton.nico...@gmail.com wrote: Maybe #ensureDeleted would be better? Nico I like #ensureDeleted (make sure it doesn't exist)
[Pharo-project] Jenkins downloads broken?
I have been trying to grab 2.0 from Jenkins - no luck. There are long connection delays and then incomplete downloads (512 bytes per file) if it does finally connect. Anybody else seeing this? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [s...@clipperadams.com] Sent: Thursday, June 07, 2012 12:11 AM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Backporting fixes I want to backport some fixes from 2.0 into 1.4. What's the best way to do that? Also, it seems to me that, given our new development process, all bugs should be tagged for both 1.4 and 2.0 unless they specifically don't apply to 1.4... Thanks, Sean -- View this message in context: http://forum.world.st/Backporting-fixes-tp4633625.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Jenkins downloads broken?
No worries. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Esteban Lorenzano [esteba...@gmail.com] Sent: Thursday, June 07, 2012 3:06 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Jenkins downloads broken? yes... we are experimenting some infrastructure issues. Please be patient :) Esteban On Jun 7, 2012, at 9:01 PM, Schwab,Wilhelm K wrote: I have been trying to grab 2.0 from Jenkins - no luck. There are long connection delays and then incomplete downloads (512 bytes per file) if it does finally connect. Anybody else seeing this? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [s...@clipperadams.com] Sent: Thursday, June 07, 2012 12:11 AM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Backporting fixes I want to backport some fixes from 2.0 into 1.4. What's the best way to do that? Also, it seems to me that, given our new development process, all bugs should be tagged for both 1.4 and 2.0 unless they specifically don't apply to 1.4... Thanks, Sean -- View this message in context: http://forum.world.st/Backporting-fixes-tp4633625.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Progress bar in the top left
There are times when it is necessary to protect the user from themselves. Modal to a particular window can be a VERY good thing. Several years ago, I remember watching in horror as my chairman was tinkering with a UI I had created that was not sufficiently modal, and he was at extreme risk of losing a lot of work as a result. You had to be there... BTW, he's a great guy and would have put it down to a learning experience for us both, not to mention a major bug report. I promptly made it modal, and all was well for years after that. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, May 25, 2012 9:12 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Progress bar in the top left I meant modal. Since when? Rule #1 of UI: never block UI. Because if you do, then we have no right to call it UI. do you know why we need this panic button (Alt-.) in our images? Exactly because every silly thing prefers to block UI at any point, even if it doesn't necessary. stef
Re: [Pharo-project] Short rant on platforms and sessions
It's a nice system - we should take lessons from it where we can. In this case, they *clearly* have it right. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Chris Muller [asquea...@gmail.com] Sent: Thursday, May 10, 2012 8:56 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Short rant on platforms and sessions Dolphin shows us the correct path: session awareness. The image wakes up and decides where it is running - the vm can certainly help in Pharo's case. External resources are *not* cleared on image save - the image might keep running, so why release and reallocate? Finalization is best-effort. External resources are cleared just before exiting, but *after* any associated image save. When the image wakes, one of its first duties is to clear (not release via calls) any external resources, because they are known to be garbage at this point. It works, and works well. I don't have experience with Dolphin, but that does sound like a clever solution to avoiding the release/reallocate burden on image save (and not exiting)..
[Pharo-project] Help reading dump?
The attached is diagnostic output from the Linux vm. I am doing some iterative numerical analysis that won't always work out, so I expect errors and non-sense results at times - it all depends on whether a particular segment of a signal is clean or noisy; if the latter, all assumptions are off. One thought is that early terminated iterations (or maybe ones that go too long?) are leaving conditions that finalization can't clean, or maybe does not clean before the next iteration begins. A segmentation fault seems a bit harsh, but they are happening and I need to find a way around them. Is there anything in the attached dump that strikes you as significant? Maybe something that says whether its the main thread or a background thread that's blowing up, or some other clue that is obvious to the correct eye? As it is, I see the #iterate, #basicIterate part of the stack, which is what I would expect the code to be trying to do - fit curves to data. The numbers at the beginning are trace info (using C++ cout) to confirm sanity of the arriving parameters. My next thought is to add some more tracing to show which segment/harmonic is being attacked as it blows up. Then I might be able to set clever breakpoints and get some handle on it. Suggestions are welcome. Bill 3.84332, 159.931, 10, 0 0.252894, 160.18, 8.73278, 1.99397 0.363713, 162.61, -5.56574, 1.91691 0.406021, 158.902, -6.61765, 1.78256 0.476139, 161.661, -0.847231, 1.86377 0.443637, 160.522, -4.42418, 1.80868 0.642492, 159.791, -2.18963, 1.81761 0.854183, 159.789, -1.99611, 1.82227 0.871482, 159.755, -1.96293, 1.82381 0.87706, 159.75, -1.93602, 1.82439 0.879748, 159.746, -1.92292, 1.82468 0.88122, 159.744, -1.91565, 1.82484 0.88201, 159.742, -1.91172, 1.82492 0.882438, 159.742, -1.90959, 1.82497 2.39318, 319.862, 10, 0 0.0935282, 318.855, 10.483, 0.95778 0.132092, 291.936, 23.2482, 0.946977 0.404741, 286.511, 90.6253, 0.743347 0.40552, 297.412, 55.0622, 0.78601 0.559505, 288.964, 41.8772, 0.641286 0.592713, 291.725, 49.7446, 0.606994 0.556732, 294.807, 41.7991, 0.651978 0.574372, 294.587, 43.5269, 0.634792 0.571113, 294.582, 43.1516, 0.638791 0.572444, 294.57, 43.2916, 0.637277 0.572065, 294.572, 43.2524, 0.637714 2.00447, 479.794, 10, 0 0.0485983, 478.956, 9.53138, 0.621548 0.0598085, 453.982, -3.80809, 0.616004 0.136859, 457.828, -25.9259, 0.587593 0.380803, 434.012, -61.677, 0.41096 0.514817, 434.418, -57.964, 0.332136 0.516887, 434.319, -59.3576, 0.3296 0.516527, 434.329, -59.2417, 0.330178 0.516577, 434.329, -59.2527, 0.330112 875.959, 160.98, 10, 0 165.085, 160.663, 7.65231, 80.477 244.706, 159.275, -0.545959, 43.1779 -6.47292, 159.345, -3.01888, 39.7121 -6.47292, 159.345, -3.01888, 39.7121 226.196, 159.334, -2.34642, 41.7332 336.516, 160.185, -2.56796, 31.1009 482.184, 159.807, -1.87057, 21.9256 515.095, 159.931, -1.9124, 22.8043 514.837, 159.926, -1.92266, 22.5313 514.748, 159.927, -1.92351, 22.5197 35.2365, 321.96, 10, 0 2.64987, 321.54, 9.36841, 2.5711 2.90632, 316.764, 1.48881, 2.52433 2.83182, 317.069, 2.39086, 2.48674 2.49402, 319.042, 6.47557, 2.31782 3.85542, 319.895, 2.54061, 2.32859 7.75149, 320.176, 0.587537, 2.39503 20.9613, 319.615, -0.0445903, 2.50059 12.1858, 319.662, 0.411797, 2.52658 8.69721, 319.828, 0.580216, 2.5 8.89274, 320.031, 0.643478, 2.51258 9.57029, 320.012, 0.532749, 2.53454 11.0239, 320.056, 0.349041, 2.5635 14.0907, 319.972, 0.190767, 2.58978 17.2841, 320.244, 0.370076, 2.49777 14.6802, 320.275, 0.396198, 2.49779 14.1189, 320.11, 0.274843, 2.5871 14.153, 320.036, 0.26973, 2.58656 14.3717, 320.074, 0.234666, 2.58685 14.4447, 320.001, 0.226596, 2.58688 14.3954, 320.048, 0.229891, 2.58687 14.4754, 320.052, 0.218954, 2.58723 14.6344, 320.038, 0.205176, 2.58814 14.7012, 320.084, 0.209725, 2.58821 14.6563, 320.054, 0.206452, 2.58823 14.7035, 320.046, 0.202856, 2.58845 14.7434, 320.057, 0.202046, 2.58861 14., 320.045, 0.199682, 2.58875 14.8119, 320.058, 0.199743, 2.58886 14.846, 320.044, 0.197638, 2.58898 14.8801, 320.059, 0.1981, 2.58908 14.9095, 320.045, 0.19643, 2.58916 14.9427, 320.058, 0.196671, 2.58923 14.9759, 320.045, 0.19491, 2.58931 15.0089, 320.059, 0.195579, 2.58936 15.0373, 320.045, 0.194176, 2.58941 15.0696, 320.058, 0.194594, 2.58945 15.1019, 320.044, 0.193052, 2.58949 15.1311, 320.058, 0.193822, 2.5895 15.1621, 320.045, 0.192392, 2.58953 15.1929, 320.059, 0.193057, 2.58953 15.2237, 320.045, 0.191701, 2.58954 15.2544, 320.059, 0.19256, 2.58953 15.2698, 320.052, 0.191878, 2.58952 10.9782, 482.941, 10, 0 0.990227, 482.427, 9.07079, 0.912732 1.16276, 477.388, -1.17699, 0.902364 1.09566, 477.884, 0.426143, 0.887859 0.888567, 479.976, 5.39541, 0.843331 2.16923, 480.015, -3.79898, 0.855822 2.94358, 479.849, -0.62964, 0.844351 8.10663, 480.069, -0.242907, 0.849423 -2.25109, 479.942, -0.615508, 0.859584 6.65604, 479.961, -0.399189, 0.861256 8.11033, 479.897, -0.412508, 0.859001 9.99394, 479.934, -0.350974, 0.854501 10.1969, 479.927, -0.353056, 0.854841 10.2004, 479.928, -0.352932,
Re: [Pharo-project] Help reading dump?
Eliot, Replacing the Smalltalk code with C would be daunting task. I had a similar idea, which was to write something that does the iteration in one function. That would be more manageable, but when faced with the reality of doing even that, I was reminded that one scenario worked perfectly, and one was giving goofy results. The latter might have been an illconditioned model. A slightly simpler model fits the data without getting itself in a twist. Some additional diagnostic output will show me what happened just before a segment fault. It's possible that I'm accessing some undefined state after a failed iteration, or something equally silly. Still, I think the segment faults are overkill/suspicious. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.mira...@gmail.com] Sent: Wednesday, May 09, 2012 11:58 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Help reading dump? On Wed, May 9, 2012 at 8:16 AM, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: The attached is diagnostic output from the Linux vm. I am doing some iterative numerical analysis that won't always work out, so I expect errors and non-sense results at times - it all depends on whether a particular segment of a signal is clean or noisy; if the latter, all assumptions are off. One thought is that early terminated iterations (or maybe ones that go too long?) are leaving conditions that finalization can't clean, or maybe does not clean before the next iteration begins. A segmentation fault seems a bit harsh, but they are happening and I need to find a way around them. Is there anything in the attached dump that strikes you as significant? Maybe something that says whether its the main thread or a background thread that's blowing up, or some other clue that is obvious to the correct eye? As it is, I see the #iterate, #basicIterate part of the stack, which is what I would expect the code to be trying to do - fit curves to data. The numbers at the beginning are trace info (using C++ cout) to confirm sanity of the arriving parameters. My next thought is to add some more tracing to show which segment/harmonic is being attacked as it blows up. Then I might be able to set clever breakpoints and get some handle on it. Suggestions are welcome. Put instrumentation around the calls that allow you to write a C program that makes the exact same calls and see if that crashes? Bill -- best, Eliot
Re: [Pharo-project] FileList efficiency could hardly be worse
This is one of those things that I find shocking. Squeak has been around for 15+ years, and still has no efficient way to get files matching a wildcard pattern (I sure couldn't find it), FFI does not (easily) support callbacks, etc. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Nicolas Cellier [nicolas.cellier.aka.n...@gmail.com] Sent: Wednesday, May 09, 2012 6:18 PM To: Pharo Development Subject: [Pharo-project] FileList efficiency could hardly be worse The efficiency of FileListlistForPattern: is something which should deserve a bit more care. It tries to sort the files, for example by name, but wants to display directory first ^ [ :x :y | |xIsDir| ((xIsDir := x isDirectory) = y isDirectory) ifTrue: [ x basename = y basename ] ifFalse: [ directories always precede files xIsDir ]] Alas, this isDirectory test cost you an arm: FileReferenceisDirectory ^ filesystem isDirectory: path FileSystemisDirectory: aResolvable Resolve the argument, and answer true if the result refers to a directory, false if it refers to a file or doesn't exist. ^ store isDirectory: (self resolve: aResolvable) FileSystemStoreisDirectory: aPath aPath isRoot ifTrue: [ ^ true ]. self nodeAt: aPath ifPresent: [ :entry | ^ self basicIsDirectory: entry ] ifAbsent: [ ^ false ]. DiskStorenodeAt: aPath ifPresent: presentBlock ifAbsent: absentBlock | name| aPath isRoot ifTrue: [ ^ presentBlock value: self rootNode ]. | encodedPath encodedBasename entry | encodedPath := Primitives encode: (self stringFromPath: aPath parent). encodedBasename := Primitives encode: aPath basename. entry := Primitives lookupDirectory: encodedPath filename: encodedBasename. ^ entry == #badDirectoryPath ifTrue: absentBlock ifFalse: [ entry at: 1 put: aPath basename. presentBlock value: entry ]. name := aPath basename. self directoryAt: aPath parent ifAbsent: absentBlock nodesDo: [ :entry | (self filename: (entry at: 1) matches: name) ifTrue: [ ^ presentBlock value: entry ] ]. ^ absentBlock value Arghh, it scans the whole parent directory again! If sort is O(n log n), then we transform it into O(2 n^2 log n). Try to browse your package-cache if you're not a chicken. Seriously, it's unusable... Nicolas
[Pharo-project] Short rant on platforms and sessions
I've been unable to follow the whole list lately, but I caught some mention of what might be a more toward platform-dependence, or lack of independence. I *like* being able to work on Linux and deploy to Windows. Hopefully we won't lose that. I agree that things should happen in the image far more than in the vm - easier to see and fix. The Smalltalk debugger is great, so we should use it at every opportunity; putting things in the image is enabling. Dolphin shows us the correct path: session awareness. The image wakes up and decides where it is running - the vm can certainly help in Pharo's case. External resources are *not* cleared on image save - the image might keep running, so why release and reallocate? Finalization is best-effort. External resources are cleared just before exiting, but *after* any associated image save. When the image wakes, one of its first duties is to clear (not release via calls) any external resources, because they are known to be garbage at this point. It works, and works well. Bill
Re: [Pharo-project] Enable #alwaysOpenFullDebugger: and fastDragging:
Options are good, but I disagree that always opening a full debugger is a good idea - I've seen meltdowns from less. YMMV. You've been warned :) From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [s...@clipperadams.com] Sent: Thursday, May 03, 2012 8:04 AM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Enable #alwaysOpenFullDebugger: and fastDragging: Debugger alwaysOpenFullDebugger: true. +1... Great idea! I didn't even know that was a setting!! UITheme currentSettings fastDragging: true. -1... Let the default be visually satisfying and people on older systems can change the setting Sean -- View this message in context: http://forum.world.st/Enable-alwaysOpenFullDebugger-and-fastDragging-tp4605379p4605826.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] What about making the configuration browser more visible?
Sounds great!! From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Wednesday, May 02, 2012 1:37 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? Let me repeat it again (reread the vision document) we will put in place a process that: - check all the configurations of a given repository (for each versions) so for example for MetaRepoForPharo1.4 and MetaRepoForPharo20… - each configuration will be loaded, test runs, rules executed. - we will have inbox for each repository, - if a configuration does not pass, it will move the configurations into an outbox Then people will be able to load configurations that have been loaded and verified. Stef
Re: [Pharo-project] What about making the configuration browser more visible?
I am using 1.3 now, but dread another round of no, install it THIS way... re 1.4. The CogVM/linux looks for stuff in the wrong places on Ubuntu, but symlinks (kinda shameful) fix that with some effort. Alien callbacks mixed with FFI do appear to be a problem, and I have some other FFI related challenges that appear to be unjust. I've been over and over the code looking for mistakes on my part, and see nothing that *should* be correlated with the error messages. Looking forward to Spok's arrival. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Norbert Hartl [norb...@hartl.name] Sent: Monday, April 30, 2012 3:54 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? Am 30.04.2012 um 00:11 schrieb Schwab,Wilhelm K: I stayed on 1.1.1 for a long time for just these reasons. If want people to test new versions, there needs to be at least some hope that they will work. To be honest I'm not sure if you should upgrade to 1.2. Just wait a little more. And then remember that it will be close to impossible to load an external module. If you don't need one, good, if not you are in serious trouble. Norbert From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [s...@clipperadams.com] Sent: Saturday, April 28, 2012 6:44 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? Dale Henrichs wrote In my last post, I provided my vision of the future That was very helpful. I can see the big picture much better now... Dale Henrichs wrote If you don't want to experience the pain of developing on a new platform, then don't move to the new platform until the hubbub has died down ... I'm perfectly happy, but it seemed like nobody knew where bill was coming from, while the API and best practices have been rapidly evolving... Sean -- View this message in context: http://forum.world.st/What-about-making-the-configuration-browser-more-visible-tp4590573p4595435.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] What about making the configuration browser more visible?
I stayed on 1.1.1 for a long time for just these reasons. If want people to test new versions, there needs to be at least some hope that they will work. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [s...@clipperadams.com] Sent: Saturday, April 28, 2012 6:44 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? Dale Henrichs wrote In my last post, I provided my vision of the future That was very helpful. I can see the big picture much better now... Dale Henrichs wrote If you don't want to experience the pain of developing on a new platform, then don't move to the new platform until the hubbub has died down ... I'm perfectly happy, but it seemed like nobody knew where bill was coming from, while the API and best practices have been rapidly evolving... Sean -- View this message in context: http://forum.world.st/What-about-making-the-configuration-browser-more-visible-tp4590573p4595435.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] What about making the configuration browser more visible?
It seems very reasonable to have such a crucial infrastructure to have some base support in the core image. But I have had experts tell me to *never* load a symbolic version. There is a gap to close... From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [s...@clipperadams.com] Sent: Saturday, April 28, 2012 12:08 AM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? Schwab,Wilhelm K wrote Put another way, if it's that simple, why all the contrary instructions over time? I understand your frustration. We are like parents watching a child grow up... For one thing, the API has been evolving as we've learned. From loadLast/Latest, to bleedingEdge/development, now to symbolic versions (which were sorely needed). The other impediment was that Metacello couldn't be assumed to have preloaded any base classes. Thus, ConfigurationOfXxx classes rely on someone manually (or automatically via tools) adding convenience methods. Without these, the API is hidden away in the project class. Recently, there seemed to be some agreement between Squeak and Pharo to load some base Metacello classes. If Configs had a common subclass, I think the system browser would be much more helpful. Dale, what do you think about all this? HTH, Sean p.s. of course ultimately, success depends on people testing projects and updating the configs... -- View this message in context: http://forum.world.st/What-about-making-the-configuration-browser-more-visible-tp4590573p4594228.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] What about making the configuration browser more visible?
No real argument, but it's not my choice - it's the only option. I had parsers not work and *COMPLETE* meltdowns that would scare away any new user, both until I followed the advice to shun the symbolic versions. Yes, there are gaps to close. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Dale Henrichs [dhenr...@vmware.com] Sent: Saturday, April 28, 2012 4:26 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? Bill, If you value the opinions of your experts over the good advice that you have received on this thread so far then that is your choice. I'd say that your experts have a gap to close... and you should expect them to close it... Dale - Original Message - | From: Wilhelm K Schwab bsch...@anest.ufl.edu | To: Pharo-project@lists.gforge.inria.fr | Sent: Saturday, April 28, 2012 11:23:14 AM | Subject: Re: [Pharo-project] What about makingthe configuration browser more visible? | | It seems very reasonable to have such a crucial infrastructure to | have some base support in the core image. But I have had experts | tell me to *never* load a symbolic version. There is a gap to | close... | | | | | From: pharo-project-boun...@lists.gforge.inria.fr | [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Sean P. | DeNigris [s...@clipperadams.com] | Sent: Saturday, April 28, 2012 12:08 AM | To: pharo-project@lists.gforge.inria.fr | Subject: Re: [Pharo-project] What about making the configuration | browser more visible? | | Schwab,Wilhelm K wrote | | Put another way, if it's that simple, why all the contrary | instructions | over time? | | | I understand your frustration. We are like parents watching a child | grow | up... | | For one thing, the API has been evolving as we've learned. From | loadLast/Latest, to bleedingEdge/development, now to symbolic | versions | (which were sorely needed). | | The other impediment was that Metacello couldn't be assumed to have | preloaded any base classes. Thus, ConfigurationOfXxx classes rely on | someone | manually (or automatically via tools) adding convenience methods. | Without | these, the API is hidden away in the project class. | | Recently, there seemed to be some agreement between Squeak and Pharo | to load | some base Metacello classes. If Configs had a common subclass, I | think the | system browser would be much more helpful. | | Dale, what do you think about all this? | | HTH, | Sean | | p.s. of course ultimately, success depends on people testing projects | and | updating the configs... | | -- | View this message in context: | http://forum.world.st/What-about-making-the-configuration-browser-more-visible-tp4590573p4594228.html | Sent from the Pharo Smalltalk mailing list archive at Nabble.com. | | |
Re: [Pharo-project] What about making the configuration browser more visible?
In the past, that hasn't been universal. More recently, I was told to *always* load specific versions; never use the symbolic versions. We have to get our story straight on this. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Camillo Bruni [camillobr...@gmail.com] Sent: Thursday, April 26, 2012 7:40 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configurationbrowser more visible? On 2012-04-27, at 01:17, Schwab,Wilhelm K wrote: Can they really download stuff? How much? Until the configurations are truly self-describing and know what to use for which version of Pharo[*], the Config Browser is really (sorry guys) a very clear illustration of what we have yet to do in the way of packaging. Bill [*] there needs to be one incantation that works to load everything, something like #loadStable. Then a config browser can work as advertised, and I fear, not until. Prove me wrong :) seems like you missed something (Metacello Configurations)? it's done like this in st-code: ConfigurationOfXYZ project load: #stable From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Thursday, April 26, 2012 6:17 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? Ok for me. Package Maps Loader Stef What about naming it Package Loader or Package center or something like that? And putting it in the main menu instead of inside of Tools? I want people who open pharo for the first time to say Hey, here I can download stuff!!! Guille
Re: [Pharo-project] What about making the configuration browser more visible?
Sorry, too many counter-examples. The situation has improved with time, but overall, it's a complicated mess with instructions that change almost weekly. Just being honest. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Guillermo Polito [guillermopol...@gmail.com] Sent: Friday, April 27, 2012 12:26 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? Wat? Probably there was a misunderstood... 1) if you are an user of the project, stable should be enough and fine. 2) if your project is coupled to the project, probably you are coupled to an specific version. Thus, in your configuration you better put the specific number :). 3) if your project is not coupled to the project, just inteded to load it, using stable should be enough and fine. Example of 2) is you loading OmniBrowser or Nautilus. Example of 3) is your project using a specific version of XmlSupport or seaside. Example of 4) is the ImageBuilder of Mariano, which loads a lot of stuff to build a Development image. Guille On Fri, Apr 27, 2012 at 5:06 PM, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: Put another way, if it's that simple, why all the contrary instructions over time? From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Camillo Bruni [camillobr...@gmail.commailto:camillobr...@gmail.com] Sent: Thursday, April 26, 2012 7:40 PM To: Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configurationbrowser more visible? On 2012-04-27, at 01:17, Schwab,Wilhelm K wrote: Can they really download stuff? How much? Until the configurations are truly self-describing and know what to use for which version of Pharo[*], the Config Browser is really (sorry guys) a very clear illustration of what we have yet to do in the way of packaging. Bill [*] there needs to be one incantation that works to load everything, something like #loadStable. Then a config browser can work as advertised, and I fear, not until. Prove me wrong :) seems like you missed something (Metacello Configurations)? it's done like this in st-code: ConfigurationOfXYZ project load: #stable From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.duca...@inria.frmailto:stephane.duca...@inria.fr] Sent: Thursday, April 26, 2012 6:17 PM To: Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? Ok for me. Package Maps Loader Stef What about naming it Package Loader or Package center or something like that? And putting it in the main menu instead of inside of Tools? I want people who open pharo for the first time to say Hey, here I can download stuff!!! Guille
Re: [Pharo-project] What about making the configuration browser more visible?
It's nice that there are examples that work, but the vast majority of configs are not so well organized. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Guillermo Polito [guillermopol...@gmail.com] Sent: Friday, April 27, 2012 12:26 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? I meant: Example of 1) is you loading OmniBrowser or Nautilus. Example of 2) is your project using a specific version of XmlSupport or seaside. Example of 3) is the ImageBuilder of Mariano, which loads a lot of stuff to build a Development image. :P On Fri, Apr 27, 2012 at 6:26 PM, Guillermo Polito guillermopol...@gmail.commailto:guillermopol...@gmail.com wrote: Wat? Probably there was a misunderstood... 1) if you are an user of the project, stable should be enough and fine. 2) if your project is coupled to the project, probably you are coupled to an specific version. Thus, in your configuration you better put the specific number :). 3) if your project is not coupled to the project, just inteded to load it, using stable should be enough and fine. Example of 1) is you loading OmniBrowser or Nautilus. Example of 2) is your project using a specific version of XmlSupport or seaside. Example of 3) is the ImageBuilder of Mariano, which loads a lot of stuff to build a Development image. Guille On Fri, Apr 27, 2012 at 5:06 PM, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: Put another way, if it's that simple, why all the contrary instructions over time? From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Camillo Bruni [camillobr...@gmail.commailto:camillobr...@gmail.com] Sent: Thursday, April 26, 2012 7:40 PM To: Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configurationbrowser more visible? On 2012-04-27, at 01:17, Schwab,Wilhelm K wrote: Can they really download stuff? How much? Until the configurations are truly self-describing and know what to use for which version of Pharo[*], the Config Browser is really (sorry guys) a very clear illustration of what we have yet to do in the way of packaging. Bill [*] there needs to be one incantation that works to load everything, something like #loadStable. Then a config browser can work as advertised, and I fear, not until. Prove me wrong :) seems like you missed something (Metacello Configurations)? it's done like this in st-code: ConfigurationOfXYZ project load: #stable From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.duca...@inria.frmailto:stephane.duca...@inria.fr] Sent: Thursday, April 26, 2012 6:17 PM To: Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? Ok for me. Package Maps Loader Stef What about naming it Package Loader or Package center or something like that? And putting it in the main menu instead of inside of Tools? I want people who open pharo for the first time to say Hey, here I can download stuff!!! Guille
Re: [Pharo-project] SSL plugin for linux
Is there an ssl socket/stream to go with it? From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguc...@gmail.com] Sent: Friday, April 27, 2012 1:29 PM To: Squeak Virtual Machine Development Discussion; Pharo Development Subject: [Pharo-project] SSL plugin for linux hi, i built ssl plugin i didn't tested but at least it find it and loads and i were able to run 1st primitive: primitiveSSLCreate Primitive. Creates and returns a new SSL handle in the VM plugin primitive: 'primitiveCreate' module: 'SqueakSSL' ^ self primitiveFailed i updated the configuration added missing source files in this commit: https://gitorious.org/cogvm/blessed/commit/59ef1cb1c70a93ed3c974b5d6beea0e4af970f15 to build SSL plugin you must have ssl, and ssl-dev libs installed: sudo apt-get install openssl sudo apt-get install libssl-dev You can download prebuilt plugin from here: http://code.google.com/p/cog/downloads/detail?name=libSqueakSSL.so.gzcan=2q=#makechanges (it is with debug info, since i used debug config to build it) To build it, you shoud use = CMakeVMMaker-IgorStasenko.157 and CogUnixConfig new addExternalPlugins: #( ... yours ... SqueakSSLPlugin ) generateSources; generate. please try plugin, if it works, so we can include it in standard build and be built automatically on jenkins server. -- Best regards, Igor Stasenko.
Re: [Pharo-project] What about making the configuration browser more visible?
I know it's not a popular opinion, but overall, they don't work. It is so bad that any effort on my part to fix one here or there would simply be sticking a finger in a collapsing Hoover dam. Yelling in general is a mis-characterization of my apparently being the only person willing to characterize the emperor's new clothes. There are wide-spread problems. Either the configs need to be fixed, or we need a common location for the latest incantation that is thought to work with a given version of Pharo. I don't know how else to put it. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Guillermo Polito [guillermopol...@gmail.com] Sent: Friday, April 27, 2012 1:37 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? On Fri, Apr 27, 2012 at 7:25 PM, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: It's nice that there are examples that work, but the vast majority of configs are not so well organized. I'm not the mantainer of the majority of configs so I do not know. What I explained before is how they are supposed to work and be managed. If the person who mantains the config does not ensure you that, It's not the problem of the configuration :). Now, if there are configs not working as expected, it would be good to: - know them - tell the mantainers - try to fix one? - not yelling in general because that does not work :S. From my side, this week I fixed the configurations of: - Glamour - OpenDBXDriver - Glorp + GlorpDBX - ScriptManager so they can load in latest 1.4. But I can't be everywhere yet :P. Also, 1.4 is has just been released, so I expect most users are moving their stuff soon. Cheers, Guille From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Guillermo Polito [guillermopol...@gmail.commailto:guillermopol...@gmail.com] Sent: Friday, April 27, 2012 12:26 PM To: Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? I meant: Example of 1) is you loading OmniBrowser or Nautilus. Example of 2) is your project using a specific version of XmlSupport or seaside. Example of 3) is the ImageBuilder of Mariano, which loads a lot of stuff to build a Development image. :P On Fri, Apr 27, 2012 at 6:26 PM, Guillermo Polito guillermopol...@gmail.commailto:guillermopol...@gmail.com wrote: Wat? Probably there was a misunderstood... 1) if you are an user of the project, stable should be enough and fine. 2) if your project is coupled to the project, probably you are coupled to an specific version. Thus, in your configuration you better put the specific number :). 3) if your project is not coupled to the project, just inteded to load it, using stable should be enough and fine. Example of 1) is you loading OmniBrowser or Nautilus. Example of 2) is your project using a specific version of XmlSupport or seaside. Example of 3) is the ImageBuilder of Mariano, which loads a lot of stuff to build a Development image. Guille On Fri, Apr 27, 2012 at 5:06 PM, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: Put another way, if it's that simple, why all the contrary instructions over time? From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Camillo Bruni [camillobr...@gmail.commailto:camillobr...@gmail.com] Sent: Thursday, April 26, 2012 7:40 PM To: Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configurationbrowser more visible? On 2012-04-27, at 01:17, Schwab,Wilhelm K wrote: Can they really download stuff? How much? Until the configurations are truly self-describing and know what to use for which version of Pharo[*], the Config Browser is really (sorry guys) a very clear illustration of what we have yet to do in the way of packaging. Bill [*] there needs to be one incantation that works to load everything, something like #loadStable. Then a config browser can work as advertised, and I fear, not until. Prove me wrong :) seems like you missed something (Metacello Configurations)? it's done like this in st-code: ConfigurationOfXYZ project load: #stable From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun
Re: [Pharo-project] What about making the configuration browser more visible?
I'm simply saying that we have a problem. When I first saw the config browser, I had hoped that it would bring the problem to light and spur a fix. As it is now, there are too many quirks and caveats for the browser to have any meaning beyond a few well-behaved items. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Guillermo Polito [guillermopol...@gmail.com] Sent: Friday, April 27, 2012 2:20 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? On Fri, Apr 27, 2012 at 8:11 PM, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: I know it's not a popular opinion, but overall, they don't work. It is so bad that any effort on my part to fix one here or there would simply be sticking a finger in a collapsing Hoover dam. Yelling in general is a mis-characterization of my apparently being the only person willing to characterize the emperor's new clothes. There are wide-spread problems. Either the configs need to be fixed, or we need a common location for the latest incantation that is thought to work with a given version of Pharo. But then you have the same problem if people commit packages that do not work. :S Providing working versions and tagging them, right now is a people problem, not a tool problem. And the same happens with python, java, javascript, .net, ruby, the OS software... I don't know how else to put it. From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Guillermo Polito [guillermopol...@gmail.commailto:guillermopol...@gmail.com] Sent: Friday, April 27, 2012 1:37 PM To: Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? On Fri, Apr 27, 2012 at 7:25 PM, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: It's nice that there are examples that work, but the vast majority of configs are not so well organized. I'm not the mantainer of the majority of configs so I do not know. What I explained before is how they are supposed to work and be managed. If the person who mantains the config does not ensure you that, It's not the problem of the configuration :). Now, if there are configs not working as expected, it would be good to: - know them - tell the mantainers - try to fix one? - not yelling in general because that does not work :S. From my side, this week I fixed the configurations of: - Glamour - OpenDBXDriver - Glorp + GlorpDBX - ScriptManager so they can load in latest 1.4. But I can't be everywhere yet :P. Also, 1.4 is has just been released, so I expect most users are moving their stuff soon. Cheers, Guille From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Guillermo Polito [guillermopol...@gmail.commailto:guillermopol...@gmail.com] Sent: Friday, April 27, 2012 12:26 PM To: Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? I meant: Example of 1) is you loading OmniBrowser or Nautilus. Example of 2) is your project using a specific version of XmlSupport or seaside. Example of 3) is the ImageBuilder of Mariano, which loads a lot of stuff to build a Development image. :P On Fri, Apr 27, 2012 at 6:26 PM, Guillermo Polito guillermopol...@gmail.commailto:guillermopol...@gmail.com wrote: Wat? Probably there was a misunderstood... 1) if you are an user of the project, stable should be enough and fine. 2) if your project is coupled to the project, probably you are coupled to an specific version. Thus, in your configuration you better put the specific number :). 3) if your project is not coupled to the project, just inteded to load it, using stable should be enough and fine. Example of 1) is you loading OmniBrowser or Nautilus. Example of 2) is your project using a specific version of XmlSupport or seaside. Example of 3) is the ImageBuilder of Mariano, which loads a lot of stuff to build a Development image. Guille On Fri, Apr 27, 2012 at 5:06 PM, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: Put another way, if it's that simple, why all the contrary instructions over time? From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo
Re: [Pharo-project] What about making the configuration browser more visible?
That would be nice to see. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, April 27, 2012 3:10 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configurationbrowser more visible? On Apr 27, 2012, at 8:38 PM, Schwab,Wilhelm K wrote: I'm simply saying that we have a problem. When I first saw the config browser, I had hoped that it would bring the problem to light and spur a fix. As it is now, there are too many quirks and caveats for the browser to have any meaning beyond a few well-behaved items. It will. Everybody should use symbolic versions to milestone their works and clients can then update. Stef
Re: [Pharo-project] What about making the configuration browser more visible?
Can they really download stuff? How much? Until the configurations are truly self-describing and know what to use for which version of Pharo[*], the Config Browser is really (sorry guys) a very clear illustration of what we have yet to do in the way of packaging. Bill [*] there needs to be one incantation that works to load everything, something like #loadStable. Then a config browser can work as advertised, and I fear, not until. Prove me wrong :) From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Thursday, April 26, 2012 6:17 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? Ok for me. Package Maps Loader Stef What about naming it Package Loader or Package center or something like that? And putting it in the main menu instead of inside of Tools? I want people who open pharo for the first time to say Hey, here I can download stuff!!! Guille
[Pharo-project] InnoSetup was: RE: One-click Windows comment
InnoSetup is very non-intrusive and flexible. The resulting installers have options for silent and very silent installation, so yes, you probably can do what you want with them. Of course, Inno and resulting setups don't do anything (or not much anyway) that can't be done from any software, but it does a nice job of putting files in known locations, updating always, only if newer, running software, etc. As an aside, it's interesting to see the term ActiveX *still* being used. This was something that MS was trying to kill a LONG time ago. I'm increasingly glad that I started tuning them out and focusing on the simple and reliable vs. getting wound up in every new technology they tried to jam down my throat. I'm much happier on Linux. But I digress. One can use Smalltalk to generate inno scripts (for a good while, I used inno to repackage MS' monthly patch madness (you had to be there...). I had code that abstracted adding files to be copied, executed, etc., or at least something like that - haven't looked at it for a few years now. With the resulting script, run the inno compiler over it, and a nicely behaved installer emerges. It was preferable to what MS was doing at the time for various reasons. And of course, one can simply write a script using Inno's or another IDE, or just a plain text editor. I took that route for installing my Dolphin-deployed executables. The script generally did a copy if newer type of installation, which worked well. With every update, would compile the inno scripts and send the installers on their way. The various target machines could then be told to look for and install the updates. After some nail-biting, the machines generally would re-appear on the grid. Every so often I'd have to unstick a box, but that was rare. The real fear was hardware failures, which was the most common reason that a machine failed to return to service. Didn't happen often, but it was bad when it did. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguc...@gmail.com] Sent: Saturday, April 21, 2012 5:43 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] One-click Windows comment On 21 April 2012 10:48, p...@highoctane.be p...@highoctane.be wrote: Inno Setup would be a good thing to use for creating a Windows installer. http://www.jrsoftware.org/isinfo.php I use it regularly. Interested in a sample? Since we're using automated builds, it is important that install packaging tools can run from command line and don't require any user interaction(s) in order to create an output. is inno installer allows to do that? Phil 2012/4/21 Marcus Denker marcus.den...@inria.fr On Apr 20, 2012, at 11:49 AM, Herby Vojčík wrote: The ideal way would probably that .bat (or .cmd or .vbs) creates the .lnk by some ActiveX magic, runs it and quits; subseuqntly .lnk could be clicked directly. We are planning of having installers for the three platforms... so we can make them more in the style that people expect. But this will be done step by step and slowly (like everything :-) For the meantime, I added a catch-all tracker for ideas how to improve the one-click: http://code.google.com/p/pharo/issues/detail?id=5643 -- Marcus Denker -- http://marcusdenker.de -- Philippe Back Helping you hit the top 3 outcomes you really want to achieve Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: p...@highoctane.be | Web: http://philippeback.eu | Blog: http://philippeback.be High Octane SPRL rue cour Boisacq 101 1301 Bierges -- Best regards, Igor Stasenko.
Re: [Pharo-project] InnoSetup was: RE: One-click Windows comment
Power to the Penguin! :) I will admit that one sore spot is the Gnome dust up. Shoot me, I really like Gnome 2.x, or have at least grown comfortable with it. KDE is a bit overdone for my tastes, so I'm probably going to land on Xubuntu. Overall, these are small annoyances compared to all the fun I left behind as I departed Windows. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of garduino [gardu...@gmail.com] Sent: Saturday, April 21, 2012 10:15 AM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] InnoSetup was: RE: One-click Windows comment Schwab,Wilhelm K wrote As an aside, it's interesting to see the term ActiveX *still* being used. This was something that MS was trying to kill a LONG time ago. I'm increasingly glad that I started tuning them out and focusing on the simple and reliable vs. getting wound up in every new technology they tried to jam down my throat. I'm much happier on Linux. Could not agree more with you! I can't understand how / why so many people/companies are using MS products, when the company proved lot of times that really don't care about its users and customers. -- View this message in context: http://forum.world.st/InnoSetup-was-RE-One-click-Windows-comment-tp4576268p4576493.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] [NativeBoost] Generic failure errors when using nil for void* and char* arguments
Sig, I wonder whether that should be on by default. I have had some real frustrations with FFI of late, and something like this might have avoided the problem. Unless it is easily discoverable, off is almost the same as non-existent. Any rumblings on Spock? It would be nice to have even a facade that unifies the FFI/NB/Alien on all platforms. It would indelicate to mention that this was supposed to happen in Januaryg. I never really expected to see it that soon, given the problems I had going from 1.1.1 to 1.3 with FFI, and my rotating errors with Alien callbacks. I changed a bunch of FFI calls (in ways that I genuinely think should not have been necessary) and retreated to C functions for GSL callbacks. The latter is frustrating, BAD for my eventually being able to release a GSL binding (make that REALLY BAD), but not all bad because C++ is a better formula translator that Smalltalk, and the number crunching runs at native speeds. I think these things *can* work - they just don't at present, and the FFI/NB/Alien split makes it hard to know what to try. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguc...@gmail.com] Sent: Friday, April 20, 2012 10:46 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [NativeBoost] Generic failure errors when using nil for void* and char* arguments On 20 April 2012 15:59, Jan van de Sandt jvdsa...@gmail.com wrote: Hello, I use NativeBoost to call some icu4c functions. This works fine most of the time. But now I run into the problem that when I pass nil as the argument value for one or more void* / char* parameters I get an error. When I pass a value or an empty ByteArray than it works. According to the icu4c documentation I should be able to pass NULL as an argument value. What am I missing? For pointers, there is an options in callouts, #optCoerceNilToNull which should be set, then you can invoke the call with nil as argument, which will convert it to C NULL. By default this option is OFF, because extra check means extra cycles. You can control a callout options by either per function call (see NBBasicExamplesreadDoubleFrom:) or for all methods of your class as a whole, like: MyClass classffiCalloutOptions by default, return all pointers as an instance of external address ^ #( + optReturnPtrAsExternalAddress + optCoerceNilToNull passing nil as pointer, will convert it to null(0) ) Jan. -- Best regards, Igor Stasenko.
Re: [Pharo-project] [NativeBoost] Generic failure errors when using nil for void* and char* arguments
Sig, For the record, you are not lazy. We'll start to live long and prosper when you get to it. Thanks! Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguc...@gmail.com] Sent: Friday, April 20, 2012 12:08 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [NativeBoost] Generic failure errors when using nil for void* and char* arguments On 20 April 2012 17:45, Schwab,Wilhelm K bsch...@anest.ufl.edu wrote: Sig, I wonder whether that should be on by default. I have had some real frustrations with FFI of late, and something like this might have avoided the problem. Unless it is easily discoverable, off is almost the same as non-existent. Well, it depends on POV. For the strictness of usage, i thought it is better to pass explicitly (NBExternalAddress value: 0) than nil, so that your code passing correct value types to function(s). Automatic coercion and weak typing is something which i hate in C, and try to avoid (smalltalk is strong typed language) i.e. unsigned long a = 1000; char x = a; producing only a compiler warning. and if you put: char x = (char) a; you can suppress it. But this is like placing a time bomb into your code, which you never know when it will explode. Weak typing is common source of many errors and bugs which is hard to find. This is one of the reasons, why i don't want nil to be a valid argument for functions expecting pointer(s) by default. Because while some library functions say that NULL is valid argument, on opposite side, there another functions which expecting a valid pointer value, and if you pass nil (as a result of not fully initialized object), you will crash the application. Any rumblings on Spock? It would be nice to have even a facade that unifies the FFI/NB/Alien on all platforms. It would indelicate to mention that this was supposed to happen in Januaryg. Yes, i am lazy guy, who cannot do much. Sorry :) The plans are still there: add callbacks support, add threading, unify Alien and NB. I never really expected to see it that soon, given the problems I had going from 1.1.1 to 1.3 with FFI, and my rotating errors with Alien callbacks. I changed a bunch of FFI calls (in ways that I genuinely think should not have been necessary) and retreated to C functions for GSL callbacks. The latter is frustrating, BAD for my eventually being able to release a GSL binding (make that REALLY BAD), but not all bad because C++ is a better formula translator that Smalltalk, and the number crunching runs at native speeds. I think these things *can* work - they just don't at present, and the FFI/NB/Alien split makes it hard to know what to try. i want that everything start working too.. so i can move on oh higher levels, since NativeBoost is infrastructural kind of project. Bill -- Best regards, Igor Stasenko.
[Pharo-project] Debugger code edits lost?
Please do not ask me how to reproduce this... :) Actually, I *think* it might be triggered by certain types of syntax errors. Bottom line is that the sometime I do a fair bit of coding in the debugger, only to find that the fruits of my labor went to oblivion and beyond. Gone - no trace of it. It has happened enough that that I believe there are legs to it. Has anyone else seen it?
Re: [Pharo-project] gamedev.net post asking about Smalltalk
Stef, What about stable relative to a given version of Pharo? I *really* think that to be useful, Metacello needs to be consistent. As it is, one seems to be left looking at blessings and guessing at what might work. The current and occasional (and very helpful) no, use THIS version... is appreciated, but hardly grounds for success. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Wednesday, April 18, 2012 11:50 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] gamedev.net post asking about Smalltalk No stable measn stable and this is good Development means that you are developing and that people use at their own risk Use stable to milestone. This way clients can work on your stable versions and milestone too their software. On Apr 16, 2012, at 3:48 PM, Igor Stasenko wrote: yes, we need to invent some conventions. Because different developers using different names and different labels for configuration versions. for instance, i avoid labeling versions as #stable , most of them are #development.. for this reason, #lastVersion, #latestVersion loads either outdated stuff, or even worse, a baseline..
[Pharo-project] Good news / bad news
The attached represents success (I think/hopeg) with getting GSL to fit a Gaussian plus a line to some data. I hope to use this to measure widths of peaks in FFTs of specific signals. The bad news is that I can't get Alien callbacks to work. Actually, the callbacks seem to work just fine, but I get invalid number of arguments and other errors as the function that calls the callbacks is either finishing up, close to that, or returns. FWIW, that call is made via FFI. The nature of the problem is not clear, and I lack the vm skill to reasonably think I could debug it. Using C functions to define the residuals and jacobians works perfectly, so I am on the (presumptuous) edge of thinking that my code is not the problem. Any ideas? Bill attachment: plplot-temp.png
Re: [Pharo-project] Debugger code edits lost?
Ok, it's not just me... From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Frank Shearar [frank.shea...@gmail.com] Sent: Wednesday, April 18, 2012 12:33 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Debugger code edits lost? On 18 April 2012 17:17, Schwab,Wilhelm K bsch...@anest.ufl.edu wrote: Please do not ask me how to reproduce this... :) Actually, I *think* it might be triggered by certain types of syntax errors. Bottom line is that the sometime I do a fair bit of coding in the debugger, only to find that the fruits of my labor went to oblivion and beyond. Gone - no trace of it. It has happened enough that that I believe there are legs to it. Has anyone else seen it? Yes, many times. In Squeak, so it might well be in those parts still common to both. I happened to be working with partial continuations, so I was actively hacking the stack in which I was debugging, but I've seen it occasionally elsewhere too. You edit the method, accept, restart... and if you open a Browser on that method the method's unchanged and versions shows no trace of your edit. frank
Re: [Pharo-project] gamedev.net post asking about Smalltalk
YES!! That's what we need. The package system must know what to do and do the correct thing in context, or it is (sorry) more trouble than it's worth. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Sean P. DeNigris [s...@clipperadams.com] Sent: Wednesday, April 18, 2012 12:38 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] gamedev.net post asking about Smalltalk Frank Shearar-3 wrote Stable version of foo relative to bar means a having a ConfigurationOfFooForPharo13, ConfigurationOfFooForPharo14, ConfigurationOfFooForSqueak44, and so on. Now that we have symbolic platforms in Metacello, one configuration specifies what to load for Pharo 1.3 vs. 1.4 vs. Squeak 4.4. Why would you make separate configs? The great thing about Metacello is that I can drop the config on any supported image and have it do the right thing... Sean -- View this message in context: http://forum.world.st/gamedev-net-post-asking-about-Smalltalk-tp4559039p4568264.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] gamedev.net post asking about Smalltalk
Fair enough. But let's face facts, there is an IT that is wrong. I submit that IT is an ever-changing no do it THIS way now[*] The people providing the code and instructions are very well intentioned, but overall, the whole thing is too complicated for anyone's good. I believe you that Metacello is not to blame. If it has the tools to fix this, then we should settle on some convention whether it is ConfigOfXYZ loadStable ConfigOfXYZ loadDev or whatever else the experts want. The point is that the consumer should have expectation that a single incantation will achieve the desired effect, every time (or as close as can be expected) and in context (1.3, 1.4, etc.). Bill [*] try figuring out what now means; it adds to the confusion over what to do. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Frank Shearar [frank.shea...@gmail.com] Sent: Wednesday, April 18, 2012 12:46 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] gamedev.net post asking about Smalltalk On 18 April 2012 17:38, Sean P. DeNigris s...@clipperadams.com wrote: Frank Shearar-3 wrote Stable version of foo relative to bar means a having a ConfigurationOfFooForPharo13, ConfigurationOfFooForPharo14, ConfigurationOfFooForSqueak44, and so on. Now that we have symbolic platforms in Metacello, one configuration specifies what to load for Pharo 1.3 vs. 1.4 vs. Squeak 4.4. Why would you make separate configs? The great thing about Metacello is that I can drop the config on any supported image and have it do the right thing... Sure. You can have N dead simple configurations or one complex configuration with N platforms. My point still stands: it's not Metacello's fault. frank Sean -- View this message in context: http://forum.world.st/gamedev-net-post-asking-about-Smalltalk-tp4559039p4568264.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] gamedev.net post asking about Smalltalk
On Ubuntu Lucid, it blows up in #forCurrentPlatform - can't find a suitable implementation. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Javier Pimás [elpochodelage...@gmail.com] Sent: Monday, April 16, 2012 10:29 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] gamedev.net post asking about Smalltalk Thank's to igor's debugging help it works in linux too. Gofer new squeaksource: 'NBOpenGL'; package: 'ConfigurationOfNBOpenGL'; load. (ConfigurationOfNBOpenGL project version: '1.0.3') load. (notice the 1.0.3 instead of 1.0.2) Please test that it works. There may be some random crashes, be careful and save your image before testing. You can test doing GLTTRenderingDemo new openInWorld. just be sure to have Tahoma and save your image. There's room for improvement in context creation waiting for anybody with some free time. cheers! On Mon, Apr 16, 2012 at 10:48 AM, Igor Stasenko siguc...@gmail.commailto:siguc...@gmail.com wrote: On 15 April 2012 16:50, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: Sig, Not intending to give you a hard time, but I went to the page, saw a -X package, and started to wonder if that might be linux support. But FWIW, I can't load any of it. The instructions failed, so I tried #load, and each variant gives some kine of DNU error. Maybe I have an inconsistent set of code loaded?? this is for X server. which usually runs on linux(es). Javier is working on that. There are couple bugs left, but we already have an updated configuration, but its not yet on public repository. @Javier, can you upload a new config of NBOpenGL to the squeaksource? In the grander view, Metacello continues to be (IMHO) a bottomless well of ever-changing load instructions. Either we need a reliable on-line grid (for Pharo x.x.x load this way...), or perhaps the configurations should carry (and automatically use) this type of information. I know it's not easy, but if we are trying to attract new users, this type of complexity is not going to help our cause. yes, we need to invent some conventions. Because different developers using different names and different labels for configuration versions. for instance, i avoid labeling versions as #stable , most of them are #development.. for this reason, #lastVersion, #latestVersion loads either outdated stuff, or even worse, a baseline.. Bill From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguc...@gmail.commailto:siguc...@gmail.com] Sent: Sunday, April 15, 2012 10:12 AM To: Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] gamedev.nethttp://gamedev.net post asking about Smalltalk On 15 April 2012 14:46, askoh as...@askoh.commailto:as...@askoh.com wrote: Some is interested in using Smalltalk for prototyping of games. http://www.gamedev.net/topic/623380-game-programming-in-smalltalk/ I think we should respond very constructively on gamedev.nethttp://gamedev.net to entice gamers to try Smalltalk. Programmers are coming to appreciate dynamic languages and we can capitalize on that. can you respond (i'm not registered there), that we have NBOpenGL :) http://www.squeaksource.com/NBOpenGL.html as guy want, a low-level binding. there's even some videos made by Lawson English running the demo. Go Smalltalk, Aik-Siong Koh -- View this message in context: http://forum.world.st/gamedev-net-post-asking-about-Smalltalk-tp4559039p4559039.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Best regards, Igor Stasenko. -- Best regards, Igor Stasenko. -- Lic. Javier Pimás Ciudad de Buenos Aires
Re: [Pharo-project] gamedev.net post asking about Smalltalk
I thought I read it was 1.4 only?? From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Tomi Neste [tomi.ne...@gmail.com] Sent: Monday, April 16, 2012 11:54 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] gamedev.net post asking about Smalltalk Is it supposed to work with the 1.3 one click package? I tried it with 1.3 on Ubuntu 10.04, copied over the Unix CogNB files, and while loading NativeBoost-Core-IgorStasenko.56 I get a ContextPart doesNotUnderstand: #simulatePrimitive:module:with:. -- tomppa
Re: [Pharo-project] gamedev.net post asking about Smalltalk
Sig, Not intending to give you a hard time, but I went to the page, saw a -X package, and started to wonder if that might be linux support. But FWIW, I can't load any of it. The instructions failed, so I tried #load, and each variant gives some kine of DNU error. Maybe I have an inconsistent set of code loaded?? In the grander view, Metacello continues to be (IMHO) a bottomless well of ever-changing load instructions. Either we need a reliable on-line grid (for Pharo x.x.x load this way...), or perhaps the configurations should carry (and automatically use) this type of information. I know it's not easy, but if we are trying to attract new users, this type of complexity is not going to help our cause. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguc...@gmail.com] Sent: Sunday, April 15, 2012 10:12 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] gamedev.net post asking about Smalltalk On 15 April 2012 14:46, askoh as...@askoh.com wrote: Some is interested in using Smalltalk for prototyping of games. http://www.gamedev.net/topic/623380-game-programming-in-smalltalk/ I think we should respond very constructively on gamedev.net to entice gamers to try Smalltalk. Programmers are coming to appreciate dynamic languages and we can capitalize on that. can you respond (i'm not registered there), that we have NBOpenGL :) http://www.squeaksource.com/NBOpenGL.html as guy want, a low-level binding. there's even some videos made by Lawson English running the demo. Go Smalltalk, Aik-Siong Koh -- View this message in context: http://forum.world.st/gamedev-net-post-asking-about-Smalltalk-tp4559039p4559039.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Best regards, Igor Stasenko.
Re: [Pharo-project] new 1.3 one click
David, Do you use FFI on Fedora? Any tricks needed to make things work? On Ubuntu with Cog, I have had to resort to making symlinks (in the vm directory) to needed libraries :( At least it works when I do that :) One hardware manufacturer told that Fedora is great for polish (no argument), but that things are in strange places. Comments? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of David Graham [da...@unthinkable.org] Sent: Wednesday, April 11, 2012 12:42 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] new 1.3 one click Fedora 16 32bit 9813 run, 9745 passes, 50 expected failures, 3 failures, 14 errors, 1 unexpected passes Failures: ReleaseTest#testUndeclared MirrorPrimitiveTests#testMirrorSize DateAndTimeTest#testPrintStringNoOffset ClassHierarchyTest#testSubclasses On 4/11/12 3:31 AM, Esteban Lorenzano wrote: Hi, I created a new 1.3 OneClick release, with latest VMs and latest image updates. Can you test it? https://gforge.inria.fr/frs/download.php/30563/Pharo-1.3-13328-OneClick.zip best, Esteban
Re: [Pharo-project] new 1.3 one click
David, Fair enough - thanks for the scouting report. I hope you are wrong about separate binaries. It would be sad enough if we had to detect the distro and act accordingly :( A candidate for that is Ubuntu's integration of dynamic library loading with dlconfig. I think they have a good idea, but Cog goes to pieces trying to decorate the library name, when the module name as given is the place to look first. I would like to see other distros implement the Ubuntu solution, because it *really* makes sense. What do you think of Gnome 3? Any recommendations to escape it (I'm not a fan). Unity is the sole reason I'm looking at other distros - given Gnome 2, I'd be an Ubuntu guy in perpetuity. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of David Graham [da...@unthinkable.org] Sent: Wednesday, April 11, 2012 2:57 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] new 1.3 one click Hi Bill, Sorry, I don't use FFI for any of my projects. No tricks, it worked out of the box... although Gnome3 appears to have hijacked alt-click for moving windows. I'm only an occasional linux user, but I'd say it's on par with Ubuntu. These two platforms are rapidly diverging and I imagine we'll have to compile separate binaries before too long. On 4/11/12 12:13 PM, Schwab,Wilhelm K wrote: David, Do you use FFI on Fedora? Any tricks needed to make things work? On Ubuntu with Cog, I have had to resort to making symlinks (in the vm directory) to needed libraries :( At least it works when I do that :) One hardware manufacturer told that Fedora is great for polish (no argument), but that things are in strange places. Comments? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of David Graham [da...@unthinkable.org] Sent: Wednesday, April 11, 2012 12:42 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] new 1.3 one click Fedora 16 32bit 9813 run, 9745 passes, 50 expected failures, 3 failures, 14 errors, 1 unexpected passes Failures: ReleaseTest#testUndeclared MirrorPrimitiveTests#testMirrorSize DateAndTimeTest#testPrintStringNoOffset ClassHierarchyTest#testSubclasses On 4/11/12 3:31 AM, Esteban Lorenzano wrote: Hi, I created a new 1.3 OneClick release, with latest VMs and latest image updates. Can you test it? https://gforge.inria.fr/frs/download.php/30563/Pharo-1.3-13328-OneClick.zip best, Esteban
Re: [Pharo-project] was Re: new 1.3 one click
I looked at Mint, but do need to actually install and play. thanks. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of David Graham [da...@unthinkable.org] Sent: Wednesday, April 11, 2012 5:08 PM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] was Re: new 1.3 one click On 4/11/12 2:37 PM, Schwab,Wilhelm K wrote: David, Fair enough - thanks for the scouting report. I hope you are wrong about separate binaries. It would be sad enough if we had to detect the distro and act accordingly :( A candidate for that is Ubuntu's integration of dynamic library loading with dlconfig. I think they have a good idea, but Cog goes to pieces trying to decorate the library name, when the module name as given is the place to look first. I would like to see other distros implement the Ubuntu solution, because it *really* makes sense. To make things even more complicated, I'm actually playing with Fedora since it's going to be the default OS for the Raspberry Pi. I'm really hoping someone picks up the GSOC CogVM Arm project, but I intend to help with this effort regardless. As an aside, I've been playing with Squeak 4.2 on the BeagleBone (headless ARM board running Angstrom linux), which compiles and runs without issue. It's really fun to read sensors and blink LEDs from smalltalk, and now a smalltalk powered robot is slowly taking shape in my workshop. :) What do you think of Gnome 3? Any recommendations to escape it (I'm not a fan). Unity is the sole reason I'm looking at other distros - given Gnome 2, I'd be an Ubuntu guy in perpetuity. Have you tried Linux Mint? Bill
Re: [Pharo-project] FFI definitions - structs
Try something like what appears below. If you search the Squeak archives,
you'll probably find some useful posts by Andreas Raab. Don't expect too much
documentation. Overall, Squeak/Pharo's FFI still falls far short of Dolphin's
(sorry, but it's true), and structure mapping is a big area of relative
weakness.
Note that you *might* have to add an instance variable and accessors to allow
the struct to hold a reference to the real target object - otherwise the GC
might pull things out from under you. Somewhere in the Dolphin image, there
are examples of the phenomenon.
HTH.
Bill
==
fields
Gsl_wavelet defineFields
struct
{
const gsl_wavelet_type *type;
const double *h1;
const double *g1;
const double *h2;
const double *g2;
size_t nc;
size_t offset;
}
^#(
( type 'Gsl_wavelet_type*' )
( h1 'double*' )
( g1 'double*' )
( h2 'double*' )
( g2 'double*' )
( nc 'long' )
( offset 'long' )
)
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] on behalf of
recursiv...@gmail.com [recursiv...@gmail.com]
Sent: Monday, April 09, 2012 8:04 AM
To: pharo-project@lists.gforge.inria.fr
Subject: [Pharo-project] FFI definitions - structs
Hi,
The FFI documentation states the following in terms of defining a C struct
fields when defining subclasses of ExternalStructure:
#
For example, a color structur might implemented so:
* first, create a new class named color in the System Browser (subclass of
ExternalStructure)
* add class method 'fields' to color
maybe, like this:
fields
^#((red 'byte')
(green 'byte')
(blue 'byte'))
##
It only mentions simple data types, int, byte etc, as do the all the examples
I've been able to find.
How do you define pointers to other structs that are fields that are part of
the C struct. E.g.
C definition:
struct Statement
{
Stmt *stmt; /* statement handle */
Resultset **rsts; /* pointer to resultset list */
Thanks
Re: [Pharo-project] [ANN] NBOpenGL update
+1. I have it loaded on Linux, but have *no* clue what to try, or if it even has hope of working (I see Win32 and Mac categories, but no linux-specifics). Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Damien Cassou [damien.cas...@gmail.com] Sent: Monday, April 09, 2012 11:04 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [ANN] NBOpenGL update On Fri, Apr 6, 2012 at 3:31 PM, Igor Stasenko siguc...@gmail.com wrote: I did not tested the update thoroughly.. so i would appreciate if people will try it out and tell how it goes. please tell us what we can do to test. I'm on linux. -- Damien Cassou http://damiencassou.seasidehosting.st Lambdas are relegated to relative obscurity until Java makes them popular by not having them. James Iry
Re: [Pharo-project] Pharo 1.4 - browse slow??
I'll have to look around, but that would probably explain what I saw. I'll play around later to see if it holds up. I'm not sure about the ID of the browser though: it's listed as Browser, and there are no other choices. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Mariano Martinez Peck [marianop...@gmail.com] Sent: Thursday, April 05, 2012 2:41 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo 1.4 - browse slow?? I found myself that Nautilus is slow the first time you open a class. Probablt it needs to cache something...then the second time you open it, it is fast. I would recommend to fill that cache during ConfigurationOfNautilus to avoid a wrong impression to the final user. Cheers On Thu, Apr 5, 2012 at 10:30 AM, Camillo Bruni camillobr...@gmail.commailto:camillobr...@gmail.com wrote: On 2012-04-05, at 01:16, Sean P. DeNigris wrote: Schwab,Wilhelm K wrote something is causing delays in either asking for a new browser or (particularly) references to the currently selected class. The browser is the only one in the image, which is listed simply as Browser Maybe related to http://forum.world.st/The-tools-are-dreadfully-slow-in-1-4-td4173491.html ? I was on Mac OS X (probably Lion at the time...) with the Cog VM (probably carbon)... Sean that bug report is in vapor-mode as well... if you find the time tryout a nautilus image: https://ci.lille.inria.fr/pharo/job/Nautilus-Release/lastSuccessfulBuild/artifact/Nautilus1.4.zip cami -- Mariano http://marianopeck.wordpress.com
[Pharo-project] Pharo 1.4 - browse slow??
I'm seeing ~1-2 second delays on any attempt to browse a class. Anyone else?
Re: [Pharo-project] Pharo 1.4 - browse slow??
I'm using Ubuntu Lucid, and the CogVM. I downloaded the most recent 1.4 and started looking at the new file list (interest in the grid), and ultimately MorphTreeMorph. It's not (reliably) reproducible, but something is causing delays in either asking for a new browser or (particularly) references to the currently selected class. The browser is the only one in the image, which is listed simply as Browser. Sorry I can't be more specific. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Bernardo Ezequiel Contreras [vonbecm...@gmail.com] Sent: Wednesday, April 04, 2012 1:38 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo 1.4 - browse slow?? which steps to reproduce? On Wed, Apr 4, 2012 at 1:43 PM, Camillo Bruni camillobr...@gmail.commailto:camillobr...@gmail.com wrote: which vm? which browser? On 2012-04-04, at 18:32, Schwab,Wilhelm K wrote: I'm seeing ~1-2 second delays on any attempt to browse a class. Anyone else?
[Pharo-project] Optimizations, Cog, cpu load??
Stef, I have my laptop downloading updates, running a vm and installing clunky windows software therein. The fan just started, so my reduced load theory seems to hold water. Something in what has been done in the image and/or vm has allowed things that once would cause my laptop to heat up to run w/o need of the fan. The fan *could* have quit, but that is now clearly not the case. Pharo is getting better. Bill
Re: [Pharo-project] PluggableTextMorph changed behavior
That's the problem - it's been any day now for a LONG time. As much as I don't enjoy pointing it out, don't wait for spoon. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Marcus Denker [marcus.den...@inria.fr] Sent: Sunday, April 01, 2012 9:33 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] PluggableTextMorph changed behavior On Apr 1, 2012, at 3:29 PM, Mark Smith wrote: On 1 Apr 2012, at 14:22, Lawson English wrote: On 4/1/12 5:40 AM, Hilaire Fernandes wrote: [...] We should have a way to track and document the changes we make in the image. Spoon will have a very fine-grained solution for this issue. Spoon will solve all of Squeak's problem since 10 years ;-) Marcus -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] [Moose-dev] SciSmalltalk
Alexandre, Fair enough, but that is *your* use. R has vast functionality, and replacing all of that would be a huge undertaking. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Alexandre Bergel [alexandre.ber...@me.com] Sent: Thursday, March 29, 2012 12:16 AM To: Pharo-project@lists.gforge.inria.fr Cc: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [Moose-dev] SciSmalltalk For what I need R, Pharo can easily be better. Just an EyeSee pdf exporter will give me enough energy to build things on top of it. Alexandre Le 28 mars 2012 à 10:21, Schwab,Wilhelm K bsch...@anest.ufl.edu a écrit : It would be great to stab the R beast through the heart. But it will be tough go given the richness of analyses that R can do. I have been tinkering with PLplot for a while, but there are some graphs for R is simply more capable, and the modeling and tests are undeniably powerful. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Alexandre Bergel [alexandre.ber...@me.com] Sent: Wednesday, March 28, 2012 8:44 AM To: Moose-related development Cc: Pharo Development Subject: Re: [Pharo-project] [Moose-dev] SciSmalltalk Hi Serge! I welcome very much this initiative. Something that I believe is important, is an pdf graph exporter (maybe based on EyeSee) and the various test distribution (e.g., CHI). The fact that these two are missing is exactly the reason why I use R and Numbers instead of Pharo. I sincerely believe that Pharo can be an alternative to R and Maple. A bit more is needed from our side however. Alexandre On 27 Mar 2012, at 21:38, Serge Stinckwich wrote: Dear all, we already discuss about that in the moose and pharo mailing-list. Maybe this is too late, but please find a small proposal for gsoc 2012 below. Name: SciSmalltalk Level: Intermediate Possible mentor: Serge Stinckwich Possible second mentor: ? Description Smalltalk has at that time no equivalent to mathematical libraries like NumPy, SciPy (Python) or SciRuby (Ruby). The goal of the SciSmalltalk project is to develop an open-source library of mathematical for the Smalltalk programming language (MIT Licence). Technical Details The development of this project is to be done in Pharo Smalltalk, but the code should be portable to other Smalltalk flavors. Numerous Smalltalk projects provide already some basic functionalities (complex and quaternions extensions, random number generator, fuzzy algorithms, LAPACK linear algebra package, Didier Besset's numerical methods, ...). A first task will be to do an audit of all the existing projects that provide some mathematical stuff and build a Pharo Configuration to load them in a fresh Pharo Smalltalk image. After that, the student help by his/her mentors will decide what are the numeric algorithms to develop in priority. The student will need to know some basic numeric algorithms usually found in such libraries. Units tests should also be provided. Benefits to the Student The student will help the Smalltalk community in a very concrete way. The student will learn to design well-designed code with tests. Benefits to the Community Having a package providing more elaborate numeric libraries is really important to develop the use Smalltalk in new domains (robotics, high performance computing, computer vision, bio-computing, ...). The lack of numeric librairies hamper the use of the Smalltalk in a scientific context at the moment. An another goal of this project is to develop a community of people interested by these topic. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/ ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-project] [Moose-dev] SciSmalltalk
It would indeed. Bringing R inside the image would be very helpful, and would lead to all kinds of abstractions, making life easier. I recently bought The Art of R Programming and have had time to only skim it. I will admit that the author's enthusiasm is a bit infectious. The R language might not be *quite* as bad as I think, though I still see it as syntax over substance run amok. At one point, I *really* tried to like Visual Basic - this was a long time ago. But every question got answered with the SYNTAX for that is ... - R seems much the same way. Very few users think in terms of objects, behavior and re-use. With bindings, we could change that (for us at least). Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Francisco Garau [francisco.ga...@gmail.com] Sent: Thursday, March 29, 2012 5:19 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [Moose-dev] SciSmalltalk There is a GSoC project to have R-bindings in Smalltalk. That would be just amazing! Very useful for a lot of applications (including finance) On 28 March 2012 15:21, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: It would be great to stab the R beast through the heart. But it will be tough go given the richness of analyses that R can do. I have been tinkering with PLplot for a while, but there are some graphs for R is simply more capable, and the modeling and tests are undeniably powerful. Bill From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Alexandre Bergel [alexandre.ber...@me.commailto:alexandre.ber...@me.com] Sent: Wednesday, March 28, 2012 8:44 AM To: Moose-related development Cc: Pharo Development Subject: Re: [Pharo-project] [Moose-dev] SciSmalltalk Hi Serge! I welcome very much this initiative. Something that I believe is important, is an pdf graph exporter (maybe based on EyeSee) and the various test distribution (e.g., CHI). The fact that these two are missing is exactly the reason why I use R and Numbers instead of Pharo. I sincerely believe that Pharo can be an alternative to R and Maple. A bit more is needed from our side however. Alexandre On 27 Mar 2012, at 21:38, Serge Stinckwich wrote: Dear all, we already discuss about that in the moose and pharo mailing-list. Maybe this is too late, but please find a small proposal for gsoc 2012 below. Name: SciSmalltalk Level: Intermediate Possible mentor: Serge Stinckwich Possible second mentor: ? Description Smalltalk has at that time no equivalent to mathematical libraries like NumPy, SciPy (Python) or SciRuby (Ruby). The goal of the SciSmalltalk project is to develop an open-source library of mathematical for the Smalltalk programming language (MIT Licence). Technical Details The development of this project is to be done in Pharo Smalltalk, but the code should be portable to other Smalltalk flavors. Numerous Smalltalk projects provide already some basic functionalities (complex and quaternions extensions, random number generator, fuzzy algorithms, LAPACK linear algebra package, Didier Besset's numerical methods, ...). A first task will be to do an audit of all the existing projects that provide some mathematical stuff and build a Pharo Configuration to load them in a fresh Pharo Smalltalk image. After that, the student help by his/her mentors will decide what are the numeric algorithms to develop in priority. The student will need to know some basic numeric algorithms usually found in such libraries. Units tests should also be provided. Benefits to the Student The student will help the Smalltalk community in a very concrete way. The student will learn to design well-designed code with tests. Benefits to the Community Having a package providing more elaborate numeric libraries is really important to develop the use Smalltalk in new domains (robotics, high performance computing, computer vision, bio-computing, ...). The lack of numeric librairies hamper the use of the Smalltalk in a scientific context at the moment. An another goal of this project is to develop a community of people interested by these topic. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/ ___ Moose-dev mailing list moose-...@iam.unibe.chmailto:moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-project] [Moose-dev] SciSmalltalk
I suspect a seamless bridge to R would prove much more useful. Lots of functionality for free. The Blue Book contributions could help shape the way we abstract R's features. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of p...@highoctane.be [p...@highoctane.be] Sent: Thursday, March 29, 2012 5:25 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] [Moose-dev] SciSmalltalk It would be just as nice to be able to integrate R through some kind of bridge. I am using R as well over here. And wxMaxima. What is interesting is that Blue book already has some interesting bits about distributions etc in the simulations part. Maybe we should already bring that material inside Pharo in a Stats-Bluebook package? Phil 2012/3/29 Alexandre Bergel alexandre.ber...@me.commailto:alexandre.ber...@me.com For what I need R, Pharo can easily be better. Just an EyeSee pdf exporter will give me enough energy to build things on top of it. Alexandre Le 28 mars 2012 à 10:21, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu a écrit : It would be great to stab the R beast through the heart. But it will be tough go given the richness of analyses that R can do. I have been tinkering with PLplot for a while, but there are some graphs for R is simply more capable, and the modeling and tests are undeniably powerful. Bill From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Alexandre Bergel [alexandre.ber...@me.commailto:alexandre.ber...@me.com] Sent: Wednesday, March 28, 2012 8:44 AM To: Moose-related development Cc: Pharo Development Subject: Re: [Pharo-project] [Moose-dev] SciSmalltalk Hi Serge! I welcome very much this initiative. Something that I believe is important, is an pdf graph exporter (maybe based on EyeSee) and the various test distribution (e.g., CHI). The fact that these two are missing is exactly the reason why I use R and Numbers instead of Pharo. I sincerely believe that Pharo can be an alternative to R and Maple. A bit more is needed from our side however. Alexandre On 27 Mar 2012, at 21:38, Serge Stinckwich wrote: Dear all, we already discuss about that in the moose and pharo mailing-list. Maybe this is too late, but please find a small proposal for gsoc 2012 below. Name: SciSmalltalk Level: Intermediate Possible mentor: Serge Stinckwich Possible second mentor: ? Description Smalltalk has at that time no equivalent to mathematical libraries like NumPy, SciPy (Python) or SciRuby (Ruby). The goal of the SciSmalltalk project is to develop an open-source library of mathematical for the Smalltalk programming language (MIT Licence). Technical Details The development of this project is to be done in Pharo Smalltalk, but the code should be portable to other Smalltalk flavors. Numerous Smalltalk projects provide already some basic functionalities (complex and quaternions extensions, random number generator, fuzzy algorithms, LAPACK linear algebra package, Didier Besset's numerical methods, ...). A first task will be to do an audit of all the existing projects that provide some mathematical stuff and build a Pharo Configuration to load them in a fresh Pharo Smalltalk image. After that, the student help by his/her mentors will decide what are the numeric algorithms to develop in priority. The student will need to know some basic numeric algorithms usually found in such libraries. Units tests should also be provided. Benefits to the Student The student will help the Smalltalk community in a very concrete way. The student will learn to design well-designed code with tests. Benefits to the Community Having a package providing more elaborate numeric libraries is really important to develop the use Smalltalk in new domains (robotics, high performance computing, computer vision, bio-computing, ...). The lack of numeric librairies hamper the use of the Smalltalk in a scientific context at the moment. An another goal of this project is to develop a community of people interested by these topic. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/ ___ Moose-dev mailing list moose-...@iam.unibe.chmailto:moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- Philippe Back Helping you hit the top 3 outcomes you really want
Re: [Pharo-project] SciSmalltalk
Do we really want Smalltalk code, or a wrapper around a C library? I've been tackling GSL, but callbacks+ffi have gotten strange. Still, it seems that for 500k element FFTs and other tricks, C _has_ to be faster than what we can create in Smalltalk. I am not at all thrilled about GSL's license. Maybe there is a better choice? To its credit, it is fairly full featured, including wavelet transforms, which are very useful. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Serge Stinckwich [serge.stinckw...@gmail.com] Sent: Wednesday, March 28, 2012 1:24 AM To: Pharo Development; Moose-related development Subject: Re: [Pharo-project] SciSmalltalk BTW, i'm looking for some Smalltalk code implementing Runge-Kutta methods for solving a set of ordinary differential equations (ODEs). Regards, On Wed, Mar 28, 2012 at 8:38 AM, Serge Stinckwich serge.stinckw...@gmail.com wrote: Dear all, we already discuss about that in the moose and pharo mailing-list. Maybe this is too late, but please find a small proposal for gsoc 2012 below. Name: SciSmalltalk Level: Intermediate Possible mentor: Serge Stinckwich Possible second mentor: ? Description Smalltalk has at that time no equivalent to mathematical libraries like NumPy, SciPy (Python) or SciRuby (Ruby). The goal of the SciSmalltalk project is to develop an open-source library of mathematical for the Smalltalk programming language (MIT Licence). Technical Details The development of this project is to be done in Pharo Smalltalk, but the code should be portable to other Smalltalk flavors. Numerous Smalltalk projects provide already some basic functionalities (complex and quaternions extensions, random number generator, fuzzy algorithms, LAPACK linear algebra package, Didier Besset's numerical methods, ...). A first task will be to do an audit of all the existing projects that provide some mathematical stuff and build a Pharo Configuration to load them in a fresh Pharo Smalltalk image. After that, the student help by his/her mentors will decide what are the numeric algorithms to develop in priority. The student will need to know some basic numeric algorithms usually found in such libraries. Units tests should also be provided. Benefits to the Student The student will help the Smalltalk community in a very concrete way. The student will learn to design well-designed code with tests. Benefits to the Community Having a package providing more elaborate numeric libraries is really important to develop the use Smalltalk in new domains (robotics, high performance computing, computer vision, bio-computing, ...). The lack of numeric librairies hamper the use of the Smalltalk in a scientific context at the moment. An another goal of this project is to develop a community of people interested by these topic. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/ -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
Re: [Pharo-project] [Moose-dev] SciSmalltalk
It would be great to stab the R beast through the heart. But it will be tough go given the richness of analyses that R can do. I have been tinkering with PLplot for a while, but there are some graphs for R is simply more capable, and the modeling and tests are undeniably powerful. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Alexandre Bergel [alexandre.ber...@me.com] Sent: Wednesday, March 28, 2012 8:44 AM To: Moose-related development Cc: Pharo Development Subject: Re: [Pharo-project] [Moose-dev] SciSmalltalk Hi Serge! I welcome very much this initiative. Something that I believe is important, is an pdf graph exporter (maybe based on EyeSee) and the various test distribution (e.g., CHI). The fact that these two are missing is exactly the reason why I use R and Numbers instead of Pharo. I sincerely believe that Pharo can be an alternative to R and Maple. A bit more is needed from our side however. Alexandre On 27 Mar 2012, at 21:38, Serge Stinckwich wrote: Dear all, we already discuss about that in the moose and pharo mailing-list. Maybe this is too late, but please find a small proposal for gsoc 2012 below. Name: SciSmalltalk Level: Intermediate Possible mentor: Serge Stinckwich Possible second mentor: ? Description Smalltalk has at that time no equivalent to mathematical libraries like NumPy, SciPy (Python) or SciRuby (Ruby). The goal of the SciSmalltalk project is to develop an open-source library of mathematical for the Smalltalk programming language (MIT Licence). Technical Details The development of this project is to be done in Pharo Smalltalk, but the code should be portable to other Smalltalk flavors. Numerous Smalltalk projects provide already some basic functionalities (complex and quaternions extensions, random number generator, fuzzy algorithms, LAPACK linear algebra package, Didier Besset's numerical methods, ...). A first task will be to do an audit of all the existing projects that provide some mathematical stuff and build a Pharo Configuration to load them in a fresh Pharo Smalltalk image. After that, the student help by his/her mentors will decide what are the numeric algorithms to develop in priority. The student will need to know some basic numeric algorithms usually found in such libraries. Units tests should also be provided. Benefits to the Student The student will help the Smalltalk community in a very concrete way. The student will learn to design well-designed code with tests. Benefits to the Community Having a package providing more elaborate numeric libraries is really important to develop the use Smalltalk in new domains (robotics, high performance computing, computer vision, bio-computing, ...). The lack of numeric librairies hamper the use of the Smalltalk in a scientific context at the moment. An another goal of this project is to develop a community of people interested by these topic. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/ ___ Moose-dev mailing list moose-...@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
[Pharo-project] Close encounters of the weird kind
Eliot, all, My GSL code, with callbacks is confusing me. First, I call gsl_multifit_fdfsolver_set(). This seems to work, hitting various callbacks (apparently successfully), but then gives an error with #'bad number of arguments'. I have looked, and don't see an invalid number of arguments anywhere. I can proceed past that(??), only to crash in gsl_multiroot_fdfsolver_iterate(). The C backtrace appears below. Is there anything I might glean from it? Any ideas? Bill C stack backtrace: /home/bills/Work2012/Pharo-1.3/CogVM[0x80968b1] /home/bills/Work2012/Pharo-1.3/CogVM[0x8096a52] [0xb7720410] /usr/lib/libgsl.so.0(gsl_multifit_fdfsolver_iterate+0x37)[0x759fc5a7] /home/bills/Work2012/Pharo-1.3/libSqueakFFIPrims.so(primitiveCallout+0x4b2)[0x75c682a2] /home/bills/Work2012/Pharo-1.3/CogVM(interpret+0x3f68)[0x808dcc8] /home/bills/Work2012/Pharo-1.3/CogVM[0x808fc97] /home/bills/Work2012/Pharo-1.3/CogVM[0x8090664] /home/bills/Work2012/Pharo-1.3/CogVM(main+0x38a)[0x809774a] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7580bd6] /home/bills/Work2012/Pharo-1.3/CogVM[0x805acc1]
Re: [Pharo-project] Silly question: how to start up pharo on a given image?
Stefano, Don't worry about the noise - I'm glad you solved your problem. The following are some things that might help you or others in the future. To run latest versions off of Jenkins on Ubuntu, I just dump the image, changes, and Cog.zip contents into one directory and then have a one-line shell script, something like this: /home/bills/Pharo-1.4/CogVM /home/bills/Pharo-1.4/Seaside.image - vm -- - image On Ubuntu at least, Cog looks for .so love in all the wrong places. The best solution I have found (it's ugly) is to create sim links (in the common folder, to wherever the library might be) to each library I want Cog to be able to see. I have a plain text file called links.txt to help me. The first few lines are ln -s /usr/lib/libplplotd.so.9 ./libplplotd.so.9 ln -s /usr/lib/libAccesIO-USB.so ./libAccesIO-USB.so ln -s /lib/libc.so.6 ./libc.so.6 Faced with a new machine, I can simply issue these commands in a terminal to make the libraries visible. AFAIK, what Cog should be doing (at least as a first attempt to find a library) is to look for the library as named in #moduleName. Ubuntu ties its dynamic loading of libraries to ldconfig's database, which anyone can read and only sudo can modify. It is s a clever approach to the problem. For example, on my machine, running ldconfig -p | grep libplplotd.so.9 returns libplplotd.so.9 (libc6) = /usr/lib/libplplotd.so.9 Asking to load libplplotd.so.9 will cause the system to load /usr/lib/libplplotd.so.9. That is simply reading the map, which does not require root access. If you want to add a library, you would either use ldconf.d or simply place the library in usr/lib and then run (as sudo) ldconfig, which scans the default locations and ldconfig.d scripts to rebuild the database. Right or wrong, this approach seems to work for me. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of stefano franchi [stefano.fran...@gmail.com] Sent: Monday, March 26, 2012 6:35 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Silly question: how to start up pharo on a given image? Ok, it was silly. Looking at the pharo.sh script made it clear. Sorry for the noise. Cheers, Stefano On Mon, Mar 26, 2012 at 5:13 PM, stefano franchi stefano.fran...@gmail.com wrote: Dear all, this may be a silly question, but I can't find the answer in the pharo book or on the list: how do you start pharo on a specific image? in Visualworks, you'd do $vw imagename and from then on, the image and change file would be saved in imagename's directory. But in pharo, it seems the imagename I give on the command line is ignored, and I always start with the default image (which, on my archlinux system, is located at /usr/share/pharo). Since that directory is not writable by default and it contains the change file, I get all sort of errors. Perhaps it is an installation issue? Cheers, Stefano -- __ Stefano Franchi Associate Research Professor Department of Hispanic StudiesPh: +1 (979) 845-2125 Texas AM University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org -- __ Stefano Franchi Associate Research Professor Department of Hispanic StudiesPh: +1 (979) 845-2125 Texas AM University Fax: +1 (979) 845-6421 College Station, Texas, USA stef...@tamu.edu http://stefano.cleinias.org
[Pharo-project] FFI error message: Heisenbug
I'm working on GSL+callbacks, and have hit a genuine Heisenbug - the behavior changes depending on when/where I break and/or step over or into code. Callbacks are getting hit successfully(!!!) but there is one function that crashes, unless I step over the call, in which case I get an error. In particular, if I step far enough into things to see the call, calling gsl_multifit_fdfsolver_set() is raising an error (vs. crashing if I don't lookg) that says 'No module to load address from'. Anybody know what that means? I'm using the CogVM on Ubuntu Lucid. Bill
Re: [Pharo-project] FFI error message: Heisenbug
Eliot, I didn't think of that, but your NotInLibrary() test works in that it raises a not-found error. So it looks like gsl_multifit_fdfsolver_set() is available. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.mira...@gmail.com] Sent: Sunday, March 25, 2012 3:35 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI error message: Heisenbug On Sun, Mar 25, 2012 at 9:55 AM, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: I started asking whether the setter function might somehow not be visible through my wrapper .so. Running objdump -T /home/bills/Work2010/gslWrapper/bin/Release/libgslWrapper.so | grep gsl_multifit_fdfsolver_set gives nothing, but my experience has been the wrapper magically exports everything from blas and gsl, but I'm not sure how to list all of the exports. Regardless, Alien lookup:'gsl_multifit_fdfsolver_set' inLibrary:'libgslWrapper.so' returns an Alien with a handle, so can I assume that the function is indeed exported by the wrapper? yes. But have you thought to confirm by trying Alien lookup:'this_is_not_in_the_library' inLibrary:'libgslWrapper.so' ? Bill From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu] Sent: Sunday, March 25, 2012 12:36 PM To: pharo-project@lists.gforge.inria.frmailto:pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] FFI error message: Heisenbug I'm working on GSL+callbacks, and have hit a genuine Heisenbug - the behavior changes depending on when/where I break and/or step over or into code. Callbacks are getting hit successfully(!!!) but there is one function that crashes, unless I step over the call, in which case I get an error. In particular, if I step far enough into things to see the call, calling gsl_multifit_fdfsolver_set() is raising an error (vs. crashing if I don't lookg) that says 'No module to load address from'. Anybody know what that means? I'm using the CogVM on Ubuntu Lucid. Bill -- best, Eliot
Re: [Pharo-project] FFI error message: Heisenbug
Eliot, Ok, I'm chewing on that :) Thanks. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.mira...@gmail.com] Sent: Sunday, March 25, 2012 3:46 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FFI error message: Heisenbug On Sun, Mar 25, 2012 at 9:36 AM, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: I'm working on GSL+callbacks, and have hit a genuine Heisenbug - the behavior changes depending on when/where I break and/or step over or into code. Callbacks are getting hit successfully(!!!) but there is one function that crashes, unless I step over the call, in which case I get an error. In particular, if I step far enough into things to see the call, calling gsl_multifit_fdfsolver_set() is raising an error (vs. crashing if I don't lookg) that says 'No module to load address from'. Anybody know what that means? I'm using the CogVM on Ubuntu Lucid. That's the error associated with FFIErrorNoModule, see ExternalFunction classinitializeErrorMessages. An FFI call will fail with this when it can't find the call address in the first method literal (or when doing ExternalFunctioninvokeWithArguments and the receiver doesn't have a call address). Bill -- best, Eliot
[Pharo-project] Seaside Book: Chapter 17, Serving Files
Stef, Thanks for Dynamic Web Development With Seaside - it's a great book! One omission that I have noted is that of dynamically serving files. Making a long story short, I have a Seaside app that swallows and regurgitates literature (300 MB and growing). It is what has me interested in Citezen (which is working wonderfully - thanks again!). I wish I had known more about Seaside when I started to write it, but it is slowly improving. Clearly, I can't put hundreds of megabytes in a FileLibrary, and I have no interest in configuring a static web server for something that (sadly or not) runs locally on multiple machines, with data synchronized via what amounts to an rsynch clone and ever-growing flash sticks. The answer is to serve the content dynamically, as below. I think this technique deserves mention in Chapter 17. Bill serveFileNamed:fileName for:component canvas:html | mimeType | ( File splitExtensionFrom:fileName ) = 'pdf' ifTrue:[ mimeType := 'application/pdf' ]. ( File splitExtensionFrom:fileName ) = 'txt' ifTrue:[ mimeType := 'application/text' ]. ( File splitExtensionFrom:fileName ) = 'gz' ifTrue:[ mimeType := 'application/x-gzip' ]. component session requestContext respond:[ :response | response document:self fullTextAsString mimeType:mimeType fileName:fileName; doNotCache ]
Re: [Pharo-project] Seaside Book: Chapter 17, Serving Files
Francois, I am probably missing something toog, but dynamically serving the documents is EASY, and that message should get out. The app in question originally ran on a server. At first, that was a way to get around my lack (at the time) of good file synchronizing on Linux - I have long since ported to Pharo a tool that I have use for years so that it runs on Linux. That makes it easy to move files from one machine to another (basically between desktop and laptop). Having the system on a server offered the option for others to see the data, but they never used it. IT policies became problematic (or at least scary), and it is simply easier for to run it locally, so I took that plunge. The system has security features that make little sense now; I might remove them some day. When it ran on a server, I simply generated urls for the full text articles. At present, serving the files dynamically just works and does it w/o the need to think about servers and URLs. It is a nice solution that I think deserves mention along with FileLibrary and other methods. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Francois Stephany [tulipe.mouta...@gmail.com] Sent: Sunday, March 25, 2012 11:23 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Seaside Book: Chapter 17, Serving Files Hi Bill, I probably miss something in the use case but why don't you simply serve that static content with Kom or Zinc ? On 25/03/12 18:29, Schwab,Wilhelm K wrote: Clearly, I can't put hundreds of megabytes in a FileLibrary, and I have no interest in configuring a static web server for something that (sadly or not) runs locally on multiple machines, with data synchronized via what amounts to an rsynch clone and ever-growing flash sticks.
Re: [Pharo-project] 1.4 is now green...
Stef, Naive question: could you simply let Jenkins do the testing, and investigate/roll-back if it reports problems? If Jenkins can reliably, based on unit tests, report a last successful build, you might be at a good place. In that world, you would integrate and let Jenkins tell you if it was a bad thing to do. Like I said, it might be naive. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Saturday, March 24, 2012 10:37 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.4 is now green... .. 1.4 has now all tests green on jenkins (Mac and Linux). The nice side-effect is that all the jobs that check VM builds are now green, too. https://ci.lille.inria.fr/pharo/view/Pharo%201.4/ The idea is to now to just never ever integrate anything that makes a test break... ok but it means that we should run 20 min tests each we integrate something…. how boring. We can try. Stef That's why you should use a full automatized process :whistle: ^^ indeed. I want :) Stef
Re: [Pharo-project] no Complex class in Pharo?
Stef, One thing that must not happen is automatic use of complex numbers. Things like -1 sqrt should raise an error. If one wants a complex result, then -1 asComplex sqrt would be a nice choice. That way, one can choose whether or not complex numbers are viable - many times, they are not wanted. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Saturday, March 24, 2012 4:29 PM To: Pharo-project@lists.gforge.inria.fr; lengli...@cox.net Subject: Re: [Pharo-project] no Complex class in Pharo? On Mar 24, 2012, at 8:20 PM, Lawson English wrote: Was this done just for streamlining, or are there known bugs in the implementation of Complex in Squeak? no there were a lot of discussions three years ago about the fact that nobody used complex the implementation was not coherent Now I think that serge packaged it with its quaternium implementation. Stef L.
Re: [Pharo-project] About 1.4 Release...
Marcus, I like the idea of downstream projects but the dark side is that one won't know how much testing they have received. For one thing, the 1.4 Seaside image does not support Shout in system browsers (it works in the debugger) - 1.4 does have Shout everywhere. Someone suggested that the build scripts are not right, but my idealistic side asks why the downstream Seaside is not simply the latest 1.4 with Seaside loaded to save everybody time. I guess what I am saying is that you can pay now or pay later. Looking deeper, the pay later approach (which is what we are using) is that Pharo itself is consistent, but the end user gets stuck finding the things that would be found if Pharo were built and used (during development) in a more full featured way. I really miss the old web image, and would like to see a clean Pharo for those who must (Stef clearly finds it important - who am I to stand in his way), and a heavily advertised more fully featured image with RB, Seaside, Magritte, etc. loaded into it from the start. These are good tools that we want to promote, so we should get them tested as we go vs. dumping it on the user later. Re the RB, I enjoy having it, I choose not to use it very much. Older code accumulates lots of comments that have proven to save my skin in many situations. The RB's formatting has come a long way, but it still makes a mess of treasured resource in my old code. Refactorings that do not have to touch the code are great, and I am often willing to exploit the RB in new code that has not had time to accumulate valuable comments in cascades and other weird places. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Marcus Denker [marcus.den...@inria.fr] Sent: Friday, March 23, 2012 5:34 AM To: Pharo Development Subject: [Pharo-project] About 1.4 Release... Hi, We were discussing here about the 1.4 release... and my standpoint is: What is on the Build Server will be the Release For 1.4, this means that this image is the release image: https://ci.lille.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Pharo-1.4.zip possibly with more bugs fixed. the list is here: http://code.google.com/p/pharo/issues/list?can=2q=milestone=1.4 It especially means that we will not load additional packages (RB, OB), because then we should have used the resulting image already the last months and we did not. Is that what we want? or will people say without refactorings, I will not use it? Marcus -- Marcus Denker -- http://marcusdenker.de
Re: [Pharo-project] Little challenge for you
Stef, This reminds me of a Dolphin feature called IDE extensions. Presenters trigger an event (IIRC off of their class) when the open, and menus and commands trigger events when they are about to do something interesting. One can then easily add to an opening menu to add commands to it. As a silly but relaxing example, I had an extension that played a random sound clip when a debugger opens. It was easy with extensions, because I simply watched Debugger class for #open:aDebugger or whatever it is called, and then play the clip. I have library of short/satirical clips that can add humor to debugging sessions. More pragmatically, I had tools to help with creating acessors, compound instance creation methods, etc. It can be a very powerful feature, and all it takes is trigging some events to enable it. Dolphin makes the (IMHO **HUGE**) mistake of enabling extensions as they load. For the sake of building a new image from packages, the extensions should load and then be explicitly activated once a stable new image exists and has received a backup copy in case changes to the new system cause havoc with the operation of the extension. As was quoted recently, if your ideas are any good, you will have the cram them down people's throats. :) Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, March 23, 2012 6:09 AM To: pharo-project@lists.gforge.inria.fr Development Subject: [Pharo-project] Little challenge for you Hi guys I would love to be able to get the gofer expression automatically from the ui. I click on a package and I ask load me expression and pouf I got a gofer expressions :) Anybody wants to improve our tools? Stef
Re: [Pharo-project] About 1.4 Release...
Ok, but that kind volunteer needs an image built the way they are told to do so. The convenience factor of having big stuff loaded into an image will attract users/testers. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Frank Shearar [frank.shea...@gmail.com] Sent: Friday, March 23, 2012 6:25 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] About 1.4 Release... On 23 March 2012 09:34, Marcus Denker marcus.den...@inria.fr wrote: Hi, We were discussing here about the 1.4 release... and my standpoint is: What is on the Build Server will be the Release For 1.4, this means that this image is the release image: https://ci.lille.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Pharo-1.4.zip possibly with more bugs fixed. the list is here: http://code.google.com/p/pharo/issues/list?can=2q=milestone=1.4 It especially means that we will not load additional packages (RB, OB), because then we should have used the resulting image already the last months and we did not. Is that what we want? or will people say without refactorings, I will not use it? I'd say What is on the Build Server will be the Release is exactly the right thing to do, because it's the thing you've been testing. You can have high confidence that the artifact will be stable, etc. Adding in extra stuff increases the testing burden. Of course, you (you, or some kind volunteer) could have a job that adds the various extras, and tests that Pharo+(stuff) image. frank
Re: [Pharo-project] About 1.4 Release...
Stef, I'm not finding faults - merely encouraging good energy. For now, I am nudging a polymorph-friendly MVP framework (presenters as morph-model factories) and cleaning my GSL interface. The latter has to be done carefully, because I can't have GPL preventing me from commercial use of some of my more specialized consumers of its services. Sadly, that will limit what I can release, but I hope to provide something that will allow anyone to grab the library, install my packages (and probably a custom library to compensate for missing features and load problems on Linux), and do a lot with it. Re linux, it ships as two libraries, neither of which will load (dynamically) on its own over dependencies. They know about it, and don't seem to care. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Friday, March 23, 2012 8:21 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] About 1.4 Release... I'm working on cleaning ECompletion: now it works well in 1.4 So I guess that loading RBEngine and OB should make it. Now people should help. For 1.5 we will get nautilus. Stef Ok, but that kind volunteer needs an image built the way they are told to do so. The convenience factor of having big stuff loaded into an image will attract users/testers. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Frank Shearar [frank.shea...@gmail.com] Sent: Friday, March 23, 2012 6:25 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] About 1.4 Release... On 23 March 2012 09:34, Marcus Denker marcus.den...@inria.fr wrote: Hi, We were discussing here about the 1.4 release... and my standpoint is: What is on the Build Server will be the Release For 1.4, this means that this image is the release image: https://ci.lille.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Pharo-1.4.zip possibly with more bugs fixed. the list is here: http://code.google.com/p/pharo/issues/list?can=2q=milestone=1.4 It especially means that we will not load additional packages (RB, OB), because then we should have used the resulting image already the last months and we did not. Is that what we want? or will people say without refactorings, I will not use it? I'd say What is on the Build Server will be the Release is exactly the right thing to do, because it's the thing you've been testing. You can have high confidence that the artifact will be stable, etc. Adding in extra stuff increases the testing burden. Of course, you (you, or some kind volunteer) could have a job that adds the various extras, and tests that Pharo+(stuff) image. frank
Re: [Pharo-project] About 1.4 Release...
Yearly seems a little slow, but might be about right to allow lots of time for testing. There will always be Jenkins for those who need a fix (sometimes guilty myself). Bug fix releases would be appreciated. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Yanni Chiu [ya...@rogers.com] Sent: Friday, March 23, 2012 11:10 AM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] About 1.4 Release... On 23/03/12 5:34 AM, Marcus Denker wrote: Is that what we want? or will people say without refactorings, I will not use it? I think the release needs to happen soon, so we can all have a new baseline. According to the Pharo consortium vision doc, the release plan (maybe not for 1.4, but in the future) is to become yearly with two bug fix releases. If this were in place, then refactoring would miss the boat. Is it a big enough item to delay a release? Personally, I use it if it's in the image, and miss it slightly if it's not there. That's because I often work on a stripped down image, so others may feel differently.
Re: [Pharo-project] Pharo and an old plotter
Nice! What is the physical/electrical connection? Serial, parallel, etc.? If serial, did you have any problems with opening ports? On which VM? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Pavel Krivanek [pavel.kriva...@gmail.com] Sent: Thursday, March 22, 2012 9:47 AM To: Pharo Development Subject: [Pharo-project] Pharo and an old plotter Hi, I would like to mention one funny usage of Pharo. I have got an old simple czech plotter from 1989 named XY4150. It is no secret that the interactive environment of Smalltalk is ideal for controlling such machines because it is very easy to send commands to it and experiment with drawing capabilities. Even today such old hardware can find a real-life production deployment. I currently use it to write owner names to plastic cards with pre-printed bar codes by a special pen destined to sign credit cards :-) It is controlled by Arduino however LPT can be used too. Btw. there was several interesting czech plotters. The most interesting one was named Merkur Alfi. It was a construction set for children with two stepper motors and one relay. http://www.youtube.com/watch?v=yUmFYzyL9eo And they started to sell it recently again so if you are looking for some cool hardware for your children, you can look here: http://www.merkurtoys.cz/vyrobky/plotrovy-zapisovac-alfi-z-merkuru[1] But it's about 139€ so it's quite expensive... Cheers, -- Pavel
Re: [Pharo-project] Pharo and an old plotter
The vm really needs to tell us what is trying to do when translating names to numbers, and probably needs to ask the image for help (not sure how to do that, but these defects are all too comon). I would have thought that either a symlink or using numbers (BTW, how does THAT work? g) would be enough. Interesting about the parallel port. I have a book at home (IIRC, its The Robot Builder's Bonanza) that described using a particular type of buffer-driver chip to receive commands from a parallel port. I soon realized that quad or whatever prefix was irrelevant, and what was really going on was that the buffer-driver chip was able decode the parallel port lines (correct logic type) and the buffer business allowed it to give a little kick to things like relays. Bottom line: I had the parallel port switching relays that controlled electronic valves. It worked great. In the current world, I would probably drag out an AccesIO A/D board and use its digital outputs to do the work, but the chip did the job. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Pavel Krivanek [pavel.kriva...@gmail.com] Sent: Thursday, March 22, 2012 10:52 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo and an old plotter The plotter needs only 6 pins (gnd, pen, axe, direction, step, ready) so it can be controlled directly via LPT. I firstly successfully tried a windows machine with a parallel port. For USB connection I used Arduino with serial communication where Arduino accepts simple basic commands and when it's done it sends a message to get the next ones. It's on Linux with latest CogVM but I had to create symlink from /dev/ttyUSB0 to /dev/ttySx and open the port by number (x), not by the name. See http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg60816.html -- Pavel On Thu, Mar 22, 2012 at 2:56 PM, Schwab,Wilhelm K bsch...@anest.ufl.edu wrote: Nice! What is the physical/electrical connection? Serial, parallel, etc.? If serial, did you have any problems with opening ports? On which VM? Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Pavel Krivanek [pavel.kriva...@gmail.com] Sent: Thursday, March 22, 2012 9:47 AM To: Pharo Development Subject: [Pharo-project] Pharo and an old plotter Hi, I would like to mention one funny usage of Pharo. I have got an old simple czech plotter from 1989 named XY4150. It is no secret that the interactive environment of Smalltalk is ideal for controlling such machines because it is very easy to send commands to it and experiment with drawing capabilities. Even today such old hardware can find a real-life production deployment. I currently use it to write owner names to plastic cards with pre-printed bar codes by a special pen destined to sign credit cards :-) It is controlled by Arduino however LPT can be used too. Btw. there was several interesting czech plotters. The most interesting one was named Merkur Alfi. It was a construction set for children with two stepper motors and one relay. http://www.youtube.com/watch?v=yUmFYzyL9eo And they started to sell it recently again so if you are looking for some cool hardware for your children, you can look here: http://www.merkurtoys.cz/vyrobky/plotrovy-zapisovac-alfi-z-merkuru[1] But it's about 139€ so it's quite expensive... Cheers, -- Pavel
[Pharo-project] Custom method browser trick
Hello all, I'm working on my re-underscoring of GSL. It's been a lot of work, but I really believe it will pay off in the future in terms of being able more easily find methods of interest because with underscores, they look like the things one might find in the manual. It was *really* important with PLplot which has names that are surprisingly cryptic to start. Back to GSL, I wanted a list of methods that contain the old structure prefix (SGsl - not sure why I chose that...), are not in a category of old items, and are not simply in the old stucts (#fields, accessors). The following seems to do the job: | nav suspects | nav := SystemNavigation new. suspects := nav allMethodsWithSourceString:'SGsl' matchCase:true. suspects := suspects reject:[ :each | each category = 'public-old' or:[ each classSymbol beginsWith:'SGsl' ] ]. nav browseMessageList:suspects name: 'Methods referencing old GSL structs' autoSelect:'SGsl'. It might be a useful trick for some of you?? HTH. Bill
[Pharo-project] Dumb question: Cog and CPU temp??
Hello all, I am clobbering my cherished laptop today. I have it scanning the entire image for references and senders, but have been surprised that the fan has not started. The fan could have died, but the machine does not seem to be unusually warm. In the past, tasks like these always caused it to warm up and turn on its fan. Could Cog be the differnce Bill
Re: [Pharo-project] Custom method browser trick
One more: | nav oldSelectors senders | nav := SystemNavigation new. oldSelectors := OrderedCollection new. ( GSLLibrary allMethodsInCategory:'public-old' ) do:[ :each | oldSelectors add:each. ]. senders := OrderedCollection new. oldSelectors do:[ :each | senders addAll:( nav allSendersOf:each ). ] displayingProgress:'Old selectors'. senders := senders copyWithoutDuplicates. nav browseMessageList:senders name: 'Methods sending old GSL methods' autoSelect:'gsl'. Because of the loop over 1400 or so methods, it takes several minutes to run. It found 18 violators that I was easily able to fix in the resulting method list. Hopefully the GSL wrapper is now purged of the old methods and structs. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bsch...@anest.ufl.edu] Sent: Thursday, March 22, 2012 1:53 PM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Custom method browser trick Hello all, I'm working on my re-underscoring of GSL. It's been a lot of work, but I really believe it will pay off in the future in terms of being able more easily find methods of interest because with underscores, they look like the things one might find in the manual. It was *really* important with PLplot which has names that are surprisingly cryptic to start. Back to GSL, I wanted a list of methods that contain the old structure prefix (SGsl - not sure why I chose that...), are not in a category of old items, and are not simply in the old stucts (#fields, accessors). The following seems to do the job: | nav suspects | nav := SystemNavigation new. suspects := nav allMethodsWithSourceString:'SGsl' matchCase:true. suspects := suspects reject:[ :each | each category = 'public-old' or:[ each classSymbol beginsWith:'SGsl' ] ]. nav browseMessageList:suspects name: 'Methods referencing old GSL structs' autoSelect:'SGsl'. It might be a useful trick for some of you?? HTH. Bill
Re: [Pharo-project] Dumb question: Cog and CPU temp??
Stef, Thanks - hadn't thought of that, but it makes sense. 1.3 has been treating me well. Some of the ffi troubles I was having might have been related to the old/new confusion. I still have to pass my DOUBLEArray as void*, but maybe Sig can suggest how to make FFI aware of the type. I keep waiting for reality to crash around me, but if you had told me that, in a day, I'd have a first cut at ridding my GSL wrapper of the obsolete structs and methods, I'd have bet against it. I am still finding some broken features, but most of those were hacks to start. Thanks for the insight, and for Pharo! Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Thursday, March 22, 2012 3:16 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Dumb question: Cog and CPU temp?? On Mar 22, 2012, at 7:35 PM, Schwab,Wilhelm K wrote: Hello all, I am clobbering my cherished laptop today. I have it scanning the entire image for references and senders, but have been surprised that the fan has not started. The fan could have died, but the machine does not seem to be unusually warm. In the past, tasks like these always caused it to warm up and turn on its fan. Could Cog be the differnce Not only also the optimizations made on changes and sources. Bill
[Pharo-project] Montcello question
Is there a way to save a global variable into an MC package? I will probably just gzip some data and make a class method with the reduced byte array as a literal, but it would be nice to simply somehow tag a global and have it magically part of the package. Bill
[Pharo-project] Callback(?) debugging - bad number of arguments
Eliot, I am calling something that I *think* simply tells GSL where to find the callbacks and a relevant structure. But I am getting a primitive failure in VMCallbackContext32primReturnAs:fromContext:, which I assume means that the library is attempting to call into Pharo. In the debugger's context, ec is set to #'bad number of arguments'. I have looked at the signatures and the blocks, and the argument counts look correct at first glance, albeit toward the end of a long day. Am I being naive? Any better ideas? My next inclination is to set breakpoints in all of the callbacks to seee if any of them get hit. I can't see why they would, but it's possible - especially given other weirdness that I have observed in GSL. It work, but it's a little rough around the (design/elegance) edges at times. Bill
Re: [Pharo-project] Morpheas , bringing Morphic to Opengl (3d GUIs)
The existence of a windowed viewport suggests you are probably headed in my preferred direction. Having big text animated is nice, but I'm thinking of cubes and spheres in a scene :) A long time ago, I used Wonderland to build a poor-man's 3d cad system. I had convenience methods to (for example) arrange actors (with simple meshes applied) onto shelves and then stack the shelves. Once the (fairly pathetic) model was created, I could cause it to spin and fly around it in a crude way. It was very helpful at the time. This was based in Squeak, albeit grudgingly given the state of its UI at the time - I much prefer Pharo. I should find an old windows box and post a screenshot - I ran it not terribly long ago, and it still worked - no big surprise given the age of the machine that ran it :) The Wonderland interface was pretty annoying. Croquet's 3d object manipulation looked a lot better. But don't even get me started on tea time... The concept is valid, of course, but COMPILER CHANGES to do what could be done with event registration and some object composition?? - yuk. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Javier Pimás [elpochodelage...@gmail.com] Sent: Wednesday, March 21, 2012 11:51 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Morpheas , bringing Morphic to Opengl (3d GUIs) I just have the font rendering example that uses openGL as a backend. I saw a cube some days ago in the mailing list, is that code available to try? It is interesting in the screenshot how the blitting was caught in the middle, I didn't check why this happens. Cheers. On Tue, Mar 20, 2012 at 12:03 PM, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: +1 :) On to the more serious topic: are we bringing morphic to OpenGL (true 3D gui ala Croquet, and a BAD idea IMHO), or are we bringing OpenGL-powered 3D morphs/windows/views/whatever to embed in a 2D environment (a VERY GOOD idea IMHO). Not meaning to rain on anyone's parade, but Croquet was arguably a huge missed opportunity. Their code for manipulating 3D objects was a thing of beauty, as far as I got with evaluating it, but they pointedly (for a while) refused to let go of the 3D immersion. AFAIK, the mesh loading and object manipulation features are now available separately on Squeak Source as CroquetGL. What I am really wanting for 3D is to have one or more views on a scene, and to embed them in a traditional 2D user interface. I hope that will not get lost while any other visions advance. Options are good. Bill From: pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.frmailto:pharo-project-boun...@lists.gforge.inria.fr] on behalf of Bernardo Ezequiel Contreras [vonbecm...@gmail.commailto:vonbecm...@gmail.com] Sent: Tuesday, March 20, 2012 10:22 AM To: Pharo-project@lists.gforge.inria.frmailto:Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Morpheas , bringing Morphic to Opengl (3d GUIs) +1 On Wed, Mar 21, 2012 at 11:16 AM, Alexandre Bergel alexandre.ber...@me.commailto:alexandre.ber...@me.com wrote: I think that moat of us appreciate screenshots sent on the mailing list :-) Cheers, Alexandre Le 19 mars 2012 à 10:50, Igor Stasenko siguc...@gmail.commailto:siguc...@gmail.com a écrit : great! On 19 March 2012 16:11, Javier Pimás elpochodelage...@gmail.commailto:elpochodelage...@gmail.com wrote: I got some time and finished commiting it. Steps to load it (I tested with pharo 1.3): 1. load NBOpenGL with its configuration. 2. load NBXLib package from monticello 3. load NBOpengl-X package from monticello Then you can run the example (you'll need tahoma font): 4. add the patch I attach. 5. Do this: GLTTRenderingDemo new openInWorld. tell if something doesn't work. Cheers, Javier. On Tue, Jan 31, 2012 at 12:53 PM, Javier Pimás elpochodelage...@gmail.commailto:elpochodelage...@gmail.com wrote: Hi! IIRC: Two months ago the code was working on windows but needed some modifications to create the contexts on the other platforms. Probably Igor did that for mac now, and maybe even linux, but I have to test. I remember I was working on the NBXLib wrapper so that context creation can be done with st code on linux. I will continue with all this this week, I just have to download everything and catch up with recent changes and then I'll come back. Cheers, Javier. On Tue, Jan 31, 2012 at 10:38 AM, Igor Stasenko siguc...@gmail.commailto:siguc...@gmail.com wrote: On 31 January 2012 10:29, dimitris chloupis theki...@yahoo.co.ukmailto:theki...@yahoo.co.uk wrote: I wanted to ask if NB and COG will support windows as well, I see no windows build. there is windows build, just check downloads page
Re: [Pharo-project] Fwd: Meeting Aliens (callbacks) in the debugger - was this risky?
Sig, Great news! I'm fixing some nomenclature, after which it will be time to release the dogs on callbacks. It would be great to get me to a point of understanding them and being able to put (curve fit) function definitions back into the image. Thanks! Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Igor Stasenko [siguc...@gmail.com] Sent: Wednesday, March 21, 2012 12:19 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Fwd: Meeting Aliens (callbacks) in the debugger - was this risky? On 21 March 2012 07:40, Stéphane Ducasse stephane.duca...@inria.fr wrote: Begin forwarded message: From: Schwab,Wilhelm K bsch...@anest.ufl.edu Subject: FW: Meeting Aliens (callbacks) in the debugger - was this risky? Date: March 21, 2012 1:57:16 AM GMT+01:00 To: stephane.duca...@inria.fr stephane.duca...@inria.fr Stef, I am currently unable to post to the list (Outlook is being a pain) - could you forward this for me? I'm curious if I'm living dangerously or simply basking in Smalltalk's wonderful features. Bill From: Schwab,Wilhelm K Sent: Tuesday, March 20, 2012 8:55 PM To: pharo-project@lists.gforge.inria.fr Subject: Meeting Aliens (callbacks) in the debugger - was this risky? To see whether one can expect to set breakpoints in callback blocks, I gave it shot in #exampleCqsort: cb := Callback signature: 'int (*)(const void *, const void *)' block: [ :arg1 :arg2 | self halt. ((arg1 doubleAt: 1) - (arg2 doubleAt: 1)) sign ]. I then ran the example. To my pleasant surprise/amazement, a walkback appeared and the debugger was functional; I was able to evaluate the accessors and get numbers. Is this dangerous in some way, or does it just work? It would be hugely helpful if it is safe. Bill Should be fine. Unless you abandon the process :) But there should be a measures preventing you from doing that. -- Best regards, Igor Stasenko.
Re: [Pharo-project] Polymorph layout: images in a column
Gary,
You're good :) That might be exactly what I need. I just need to figure out
how to make it optional. My MVP framework is reducing to presenters being
factories for morph/model pairs, and I am pretty much resigning to creating
rows and columns using your Polymorph methods. It is different from Dolphin's
approach, but seeing what I have been able to do and (even more) looking at
what you have produced, it is looking like a good compromise.
My big mission is to say it once. Hopefully my humble framework will enable
that while playing nicely with Polymorph. It has various obsolete categories
to retain things that I might want to resurrect, but it is becoming usable.
Thanks!
Bill
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] on behalf of Gary Chambers
[gazzagu...@btinternet.com]
Sent: Wednesday, March 21, 2012 12:07 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: Re: [Pharo-project] Polymorph layout: images in a column
Something like the following?
(UITheme builder
newColumn: {
(UITheme builder newImage: LogoImageMorph defaultLogoForm)
hResizing: #spaceFill;
vResizing: #spaceFill;
layout: #scaledAspect})
openInWindow
Regards, Gary
- Original Message -
From: Schwab,Wilhelm Kmailto:bsch...@anest.ufl.edu
To:
pharo-project@lists.gforge.inria.frmailto:pharo-project@lists.gforge.inria.fr
Sent: Monday, March 19, 2012 8:36 PM
Subject: [Pharo-project] Polymorph layout: images in a column
Gary,
If I create a column and place an alpha image in it, is there a way to get the
image to scale, ideally to the width of the column? As it is, I'm setting
fixed extents, but somewhat works against what I would like to leave to the
column?
Bill
Re: [Pharo-project] R: Polymorph
Gary, Great stuff! One point of confusion: android _emulator_?? Does this run on Android? Just asking; I'm pretty happy with Polymorph+MVP and Seaside for things that are natural fits for web interfaces. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Lorenzo Schiavina [lore...@edor.it] Sent: Wednesday, March 21, 2012 12:44 PM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] R: Polymorph Great work! Lorenzo -Messaggio originale- Da: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] Per conto di Gary Chambers Inviato: mercoledì 21 marzo 2012 17.17 A: Pharo-project@lists.gforge.inria.fr Oggetto: Re: [Pharo-project] Polymorph Hi, still busier than a one-legged man in an arse kicking competition... there is now a vid of some stuff (awaiting my colleague getting time to do the one with the OCR/Postillion stuff) http://www.youtube.com/watch?v=xyqu3Pts0bkfeature=youtu.be enjoy Regards, Gary - Original Message - From: Germán Arduino gardu...@gmail.com To: Pharo-project@lists.gforge.inria.fr Sent: Monday, March 12, 2012 11:20 PM Subject: Re: [Pharo-project] Polymorph +1 to all (customers and videos)! 2012/3/12, Stéphane Ducasse stephane.duca...@inria.fr: On Mar 12, 2012, at 4:55 PM, Gary Chambers wrote: Sorry guys, bogged down with client work hopefully next week... I'll see if I can at least have my colleagues get some videos published in the meantime. Clients are more important :) Now we love videos of cool pharo projects! Stef -- Enviado desde mi dispositivo móvil Germán S. Arduino gsa @ arsol.net Twitter: garduino Arduino Software http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com greensecure.blogspot.com germanarduino.blogpost.com
Re: [Pharo-project] R: Polymorph
Gary, Fair enough. I was hoping to see Pharo running on Android, but I can't say I need that. Options are good. And programming in Pharo and spinning off java/android code would have its uses. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Gary Chambers [gazzagu...@btinternet.com] Sent: Wednesday, March 21, 2012 3:03 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] R: Polymorph Is a look-and-feel emulation at present. Hope to be able to generate skeleton Android Java from it though. Regards, Gary - Original Message - From: Schwab,Wilhelm K bsch...@anest.ufl.edu To: Pharo-project@lists.gforge.inria.fr Sent: Wednesday, March 21, 2012 6:53 PM Subject: Re: [Pharo-project] R: Polymorph Gary, Great stuff! One point of confusion: android _emulator_?? Does this run on Android? Just asking; I'm pretty happy with Polymorph+MVP and Seaside for things that are natural fits for web interfaces. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Lorenzo Schiavina [lore...@edor.it] Sent: Wednesday, March 21, 2012 12:44 PM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] R: Polymorph Great work! Lorenzo -Messaggio originale- Da: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] Per conto di Gary Chambers Inviato: mercoledì 21 marzo 2012 17.17 A: Pharo-project@lists.gforge.inria.fr Oggetto: Re: [Pharo-project] Polymorph Hi, still busier than a one-legged man in an arse kicking competition... there is now a vid of some stuff (awaiting my colleague getting time to do the one with the OCR/Postillion stuff) http://www.youtube.com/watch?v=xyqu3Pts0bkfeature=youtu.be enjoy Regards, Gary - Original Message - From: Germán Arduino gardu...@gmail.com To: Pharo-project@lists.gforge.inria.fr Sent: Monday, March 12, 2012 11:20 PM Subject: Re: [Pharo-project] Polymorph +1 to all (customers and videos)! 2012/3/12, Stéphane Ducasse stephane.duca...@inria.fr: On Mar 12, 2012, at 4:55 PM, Gary Chambers wrote: Sorry guys, bogged down with client work hopefully next week... I'll see if I can at least have my colleagues get some videos published in the meantime. Clients are more important :) Now we love videos of cool pharo projects! Stef -- Enviado desde mi dispositivo móvil Germán S. Arduino gsa @ arsol.net Twitter: garduino Arduino Software http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com greensecure.blogspot.com germanarduino.blogpost.com
Re: [Pharo-project] R: Polymorph
Nice! From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Gary Chambers [gazzagu...@btinternet.com] Sent: Wednesday, March 21, 2012 3:07 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] R: Polymorph To clarify, a couple of themes for HDPI and MDPI resolutions matching the Android UI (mostly). Is allowing us to present the UI to client without the compile-link-deploy cycle of Android devolpment for the moment. Have had some good seesions with virtually instant feedback. Regards, Gary - Original Message - From: Gary Chambers gazzagu...@btinternet.com To: Pharo-project@lists.gforge.inria.fr Sent: Wednesday, March 21, 2012 7:03 PM Subject: Re: [Pharo-project] R: Polymorph Is a look-and-feel emulation at present. Hope to be able to generate skeleton Android Java from it though. Regards, Gary - Original Message - From: Schwab,Wilhelm K bsch...@anest.ufl.edu To: Pharo-project@lists.gforge.inria.fr Sent: Wednesday, March 21, 2012 6:53 PM Subject: Re: [Pharo-project] R: Polymorph Gary, Great stuff! One point of confusion: android _emulator_?? Does this run on Android? Just asking; I'm pretty happy with Polymorph+MVP and Seaside for things that are natural fits for web interfaces. Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Lorenzo Schiavina [lore...@edor.it] Sent: Wednesday, March 21, 2012 12:44 PM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] R: Polymorph Great work! Lorenzo -Messaggio originale- Da: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] Per conto di Gary Chambers Inviato: mercoledì 21 marzo 2012 17.17 A: Pharo-project@lists.gforge.inria.fr Oggetto: Re: [Pharo-project] Polymorph Hi, still busier than a one-legged man in an arse kicking competition... there is now a vid of some stuff (awaiting my colleague getting time to do the one with the OCR/Postillion stuff) http://www.youtube.com/watch?v=xyqu3Pts0bkfeature=youtu.be enjoy Regards, Gary - Original Message - From: Germán Arduino gardu...@gmail.com To: Pharo-project@lists.gforge.inria.fr Sent: Monday, March 12, 2012 11:20 PM Subject: Re: [Pharo-project] Polymorph +1 to all (customers and videos)! 2012/3/12, Stéphane Ducasse stephane.duca...@inria.fr: On Mar 12, 2012, at 4:55 PM, Gary Chambers wrote: Sorry guys, bogged down with client work hopefully next week... I'll see if I can at least have my colleagues get some videos published in the meantime. Clients are more important :) Now we love videos of cool pharo projects! Stef -- Enviado desde mi dispositivo móvil Germán S. Arduino gsa @ arsol.net Twitter: garduino Arduino Software http://www.arduinosoftware.com PasswordsPro http://www.passwordspro.com greensecure.blogspot.com germanarduino.blogpost.com
[Pharo-project] Alien callback thunk as ExternalAddress?
I am getting near to jumping off the callback cliff. My problem is that I have a generated external structure that expects a void pointer (actually a function pointer). The setter sends #getHandle. I tried to hot-wire that by defining CallbackThunkgetHandle to answer the #address. Is there a way to get an ExternalAddress that points to the thunk? Should I even be asking this question? :) Bill
Re: [Pharo-project] Alien callback thunk as ExternalAddress?
Eliot, I have a lot of FFI code already written, so I am hoping to drop Alien callbacks into FFI, and a structure is being a real pain. I'll try you suggestion below, and then maybe alter the struct definition to contain integers vs. a pointer, into which FFI is making *certain* that I put only external addresses. After moving to 1.3, I had to tweak some things where I originally passed null pointers, and now integers appear to be required :( Similar forces might be at work here. CogVM, Ubuntu Lucid. Thanks! Bill From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] on behalf of Eliot Miranda [eliot.mira...@gmail.com] Sent: Wednesday, March 21, 2012 8:18 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Alien callback thunk as ExternalAddress? On Wed, Mar 21, 2012 at 4:01 PM, Schwab,Wilhelm K bsch...@anest.ufl.edumailto:bsch...@anest.ufl.edu wrote: I am getting near to jumping off the callback cliff. My problem is that I have a generated external structure that expects a void pointer (actually a function pointer). The setter sends #getHandle. I tried to hot-wire that by defining CallbackThunkgetHandle to answer the #address. But FFICallbackThunk already implements address (inherited from Alien). Why getHandle? Is there a way to get an ExternalAddress that points to the thunk? Should I even be asking this question? :) I *think* it should be ExternalAddress new fromInteger: anFFICallbackThunk address Bill -- best, Eliot
