April 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] 30838 and 837 *REVERTED*

by Marcus Denker

On 28 Apr 2014, at 16:31, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > if you downloaded 30 838 (from today) or 30 837 please re-download 837. > > Both images where broken due to things that have to be done âjust before the releaseâ, > which are, of course, broken as they are only done just before the release once a year. > The 837 available now is ok: https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-4-Publish/ http://files.pharo.org/image/30/latest.zip Marcus

April 28, 2014

30838 and 837 *REVERTED*

by Marcus Denker

Hi, if you downloaded 30 838 (from today) or 30 837 please re-download 837. Both images where broken due to things that have to be done âjust before the releaseâ, which are, of course, broken as they are only done just before the release once a year. Marcus

April 28, 2014

Re: [Pharo-users] NativeBoost

by Igor Stasenko

On 26 April 2014 09:44, Markus Fritsche <mfritsche(a)reauktion.de> wrote: > Hello, > > tl;dr: what's the reason to get aNBExternalHandle even if you expect a > MySuperHandle object from an nbCall? > > I am trying to build my first DLL wrapper with NativeBoost. I am having a > problem that instead of returning a handle object (as I thought), my > "primitive" throws NBExternalHandles at me. > > The API I am trying to wrap tries to be somewhat object oriented by > (mostly) having a handle of some sort. > > My thinking was to attach all DLL primitives to the respective Handle > Objects they take as a first parameter and go from there. > > Some workspace code: > > "Supplementary DLLs" > Tm1ULibDllLibraryLoader loadLibrary. > LibIbmCogEayLibraryLoader loadLibrary. > SslIbmCogEayLibraryLoader loadLibrary. > Log4CxxLibraryLoader loadLibrary. > "DLL to wrap" > TM1LibraryLoader loadTM1Library. > > t := TM1Api new. > t tm1APIInitialize. > hUser := t tm1SystemOpen. "Returns a proper 'TM1UHandle' object'" > hUser tm1SystemAdminHostSet: 'localhost'. > hPool1 := hUser tm1ValPoolCreate. "Returns NBExternalHandle" > hPool1 inspect. > hUser tm1SystemClose. > t tm1APIFinalize. > > TM1Api>>#tm1SystemOpen > <primitive: #primitiveNativeCall > module: #NativeBoostPlugin> > ^ self nbCall: #(TM1UHandle TM1SystemOpen(void)) > > TM1UHandle>>#tm1ValPoolCreate > <primitive: #primitiveNativeCall > module: #NativeBoostPlugin> > ^ self nbCall: #(#TM1PHandle TM1ValPoolCreate ( TM1UHandle self ) ) > > sidenote: when using 'self', you can use it without type. just say 'self', since it refers to the instance of method's class, which is enough to determine the type to use for marshalling. > Both, TM1UHandle class and TM1PHandle class have the method > asNBExternalType: gen > "use handle ivar to hold my instance (TM1x)" > ^ NBExternalObjectType objectClass: self > > and are subclasses of object. What's my mistake? Can you tell with the > information I provided? > > This is strange.. should work fine. There's no way how NBExternalObjectType could return an instance of NBExternalHandle. Please check your code again. Best regards, > Markus > > -- Best regards, Igor Stasenko.

April 28, 2014

Re: [Pharo-users] Dynamic example for spec

by kilon alios

as far as me is concerned two GUI libraries are what I would call "public relations disaster" or "an example of worst design". C++ Window's MFC and Java Swing. At the very top I put Delphi's VLC (C# winforms are a child of it) the best GUI I have dealt with and QT coming second. Spec looks fairly good from the tutorials I have seen, the ability to work hand in hand with Morphic is a big plus. However its clearly an ongoing effort, its a new library that it needs its time to mature and as Johan said Spec lacks the manpower of MFC and Swing . We should not forget that few months ago Spec was not even documented. Nonetheless I think pharo people have been doing an amazing job so far with the resources they have in their hands. It scares me to imagine the potential if Pharo community was as big and well funded as Microsoft and Sun. In the end of the day Pharo needs all the help it can get. If people start giving up every time they saw that it lacked a feature found in other libraries of other programming languages then pharo would be dead in a few days at most. Of course the same applies for every other language however popular. I completely agree that Spec is definitely an improvement and I plan to help the project with documenting it with video tutorials.

April 28, 2014

Re: [Pharo-users] Dynamic example for spec

by kmo

/It was suggested that it would be good to have other examples, so I decided to try building a more business-application related one. / Stephan - That's exactly what is needed. It's pet peeve of mine that so many of the Spec examples tend to be browsers. If Pharo wants to position itself as a general purpose application development tool then it has to demonstrate that it can create basic data entry commercial applications. Otherwise we might as well tell business developers to forget about Spec and Morphic and just use Seaside. Ken -- View this message in context: http://forum.world.st/Dynamic-example-for-spec-tp4756370p4756696.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 27, 2014

Re: [Pharo-users] Dynamic example for spec

by Stephan Eggermont

Hi kmo, Thanks for your detailed response. You seem to have run into a number of issues I havenât seen yet while learning spec. Iâll take a look at resizing windows and see how to fix the issue. I have noticed the font size issue and assumed it is to be fixed real soon now. Iâll extend the example to include editing of existing instances. It was suggested that it would be good to have other examples, so I decided to try building a more business-application related one. I am used to dealing with domain models, and will revisit the names. Stephan

April 27, 2014

Re: [Pharo-users] Dynamic example for spec

by Johan Fabry

(responses inline) On Apr 27, 2014, at 10:17 AM, kmo <voxkmp(a)gmail.com> wrote: > No one has replied to this post, so I thought I would add my two cents of > wit. Sadly, I did not have time to study the example because Iâm traveling. There are some items in this mail that however I would like to quickly respond to. (Hopefully I will have network along the way somewhere.) > Beyond that, i have to say that the example just confirms my decision not to > use Spec at all - at least in its present state. >From your comments below it is not 100% clear to me why you choose not to use Spec at all. Sure, there are some features that are missing. Are these showstoppers for you, and if so, why? Please list and explain. > Though this is supposed to be a /dynamic /Spec example, it's really not that > dynamic, is it?. You are creating separate instances of a data entry screen > here and each separate instance has its own layout - but a truly dynamic > Spec example would be one which dynamically/ changed an existing instance/. > But this cannot be done currently in Spec as there is no way to change the > size of the Spec window once it is created (Bug 13059). I do not agree with your generalization. Still it is possible to add and remove widgets on the fly, as we present in section 5.1 of the Spec chapter in the Pharo For The Enterprise book, [â¦] > One thing I had not considered before seeing your code was the consequence > of Spec's decision to call its widgets /models/. This causes (at least in my > mind) a confusion between the ideas of a model as a problem domain object > and a Spec widget. As we say in the documentation in the book: a widget is something you see on the screen with all its associated state and behavior. But with Spec you donât code the stuff you see on the screen, you just think about itâs state and behavior, i.e. the model *of the user interface*. > So, in your example, you have a /PartiesModel/ class. So > I have to look to see if this inherits from Object or Composable Model > because we now have two different ideas of model in the application. > > So in your code you have: > > DOPartyEditor>initializeWidgets > |models| > models := OrderedCollection new. > > when I read this I was thinking about models as in MVC, not as in > ComposableModel. To my mind these lines would be better written as: > > DOPartyEditor>initializeWidgets > |inputWidgets| > inputWidgets := OrderedCollection new. Or instead call them uiModels. > Finally, we have the finished product - which I would not show to anyone as > an example of a Pharo user interface. You know as well as I do that as soon > as the user types in anything they will immediately hit bug 13013 - the font > size is far too small and cannot be changed. Can you imagine in what a Java > or C# developer would think of this: /Good God these guys are so lame they > can't implement the most basic component of a data entry interface - a text > entry field. No wonder they can't get Pharo to open up two windows! And yet > they claim they have a better way of programming. What are they smoking!./ There is only so much that a group of, essentially volunteer, developers can do. Comparing it to the multi-million dollar investment that Sun/Oracle/Microsoft/ â¦ have performed is in getting their infrastructure right, inevitably will find issues. The question is: are they showstoppers? What can we do, given our situation? > Who knows what they would think if they knew that an even simpler user > interface component - the label - was buggy as well. A /LabelModel /really > only has two properties: /label /and /emphasis /and one of them doesn't > work! Can you clarify the problem? Is there a bugreport? (Iâm without network ATM, otherwise Iâd check). > I really think some of this needs to be sorted out before Pharo 3 is > released, otherwise the problems with Spec are going to give a very bad > impression to any developers who take a look at Pharo hoping to find > something better than Java or C#. A possible public relations disaster? I think you are exaggerating. Spec is already an improvement on the UI builders that precede it, and no PR disasters have happened because of these previous frameworks. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

April 27, 2014

iStoa, some news

by Hilaire Fernandes

Hi, I have been working on iStoa lately (http://launchpad.net/istoa) Few screenshot enclosed, hope for another alpha release soon. Thanks Hilaire -- Dr. Geo http://drgeo.eu

April 27, 2014

Re: [Pharo-users] Dynamic example for spec

by kmo

No one has replied to this post, so I thought I would add my two cents of wit. Many thanks for the example - any addition to the Spec documentation is really useful and I've certainly learned some stuff from your code. But I think if you are aiming to help people learn Spec, then you should add as many comments to the code as you can. Also, allowing the user to edit existing list entries would make the example much more complete. Beyond that, i have to say that the example just confirms my decision not to use Spec at all - at least in its present state. Though this is supposed to be a /dynamic /Spec example, it's really not that dynamic, is it?. You are creating separate instances of a data entry screen here and each separate instance has its own layout - but a truly dynamic Spec example would be one which dynamically/ changed an existing instance/. But this cannot be done currently in Spec as there is no way to change the size of the Spec window once it is created (Bug 13059). It is this limitation I believe that has made you take the separate instances route using a class method. The code for this just seems unnatural to me: DOPartyEditor>>on: aPartyClass ^self basicNew partyClass: aPartyClass; initialize; yourself A more natural approach would be to construct the instance as normal with /DOPartyEditor>>new/ and then set the party class. Changing the party class could then trigger the layout change, allowing the instance to rebuild itself. But this is impossible because of the window resizing issue. I think this is a clear case of Spec's limitations having a detrimental effect on code quality. One thing I had not considered before seeing your code was the consequence of Spec's decision to call its widgets /models/. This causes (at least in my mind) a confusion between the ideas of a model as a problem domain object and a Spec widget. So, in your example, you have a /PartiesModel/ class. So I have to look to see if this inherits from Object or Composable Model because we now have two different ideas of model in the application. So in your code you have: DOPartyEditor>initializeWidgets |models| models := OrderedCollection new. when I read this I was thinking about models as in MVC, not as in ComposableModel. To my mind these lines would be better written as: DOPartyEditor>initializeWidgets |inputWidgets| inputWidgets := OrderedCollection new. Finally, we have the finished product - which I would not show to anyone as an example of a Pharo user interface. You know as well as I do that as soon as the user types in anything they will immediately hit bug 13013 - the font size is far too small and cannot be changed. Can you imagine in what a Java or C# developer would think of this: /Good God these guys are so lame they can't implement the most basic component of a data entry interface - a text entry field. No wonder they can't get Pharo to open up two windows! And yet they claim they have a better way of programming. What are they smoking!./ Who knows what they would think if they knew that an even simpler user interface component - the label - was buggy as well. A /LabelModel /really only has two properties: /label /and /emphasis /and one of them doesn't work! I really think some of this needs to be sorted out before Pharo 3 is released, otherwise the problems with Spec are going to give a very bad impression to any developers who take a look at Pharo hoping to find something better than Java or C#. A possible public relations disaster? -- View this message in context: http://forum.world.st/Dynamic-example-for-spec-tp4756370p4756683.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 27, 2014

Re: [Pharo-users] [ANN] JNIPort for Pharo 3.0 alpha

by Esteban A. Maringolo

2014-04-08 16:04 GMT-03:00 Pharo4Stef <pharo4Stef(a)free.fr>: > In VW there is the concept of object bodies and head now we will eventually have that with Spur. Maybe clement explained it somewhere in his blog (I understood the point once and of course I forgot). > > Now I wonder what changed so much between 1.2 and 3.0 Dolphin's #become: uses the same concept. E.g. a become: b Doesn't switch references, but instead "body" pointers in a and b. It is, a becomes b, and b becomes a. i Time microsecondsToRun: [1000 timesRepeat: [String new become: String new ]]. 684 898 663 812 665 Also, there is a #oneWayBecome: which DOES an object table scan, and makes all references to the receiver point to the argument object (it is, a becomes b, and not the other way around). This gets slow directly proportional to the size of the OT. Time microsecondsToRun: [1000 timesRepeat: [String new become: String new ]]. 10936532 Most proxies and stubs implementations in Dolphin uses #become: because it is instantaneous, and the "old" object (b in this) eventually gets garbage collected. Regards. Esteban A. Maringolo

April 27, 2014