March 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] How to rename a package ?

by StÃ©phane Ducasse

Ok I did not read it :) indeed in that case definitively into SmallIint Stef On Mar 20, 2009, at 11:28 PM, Lukas Renggli wrote: >> For me I see that more as a menu to rename a package :) > > The script does not rename a package. It just lists the code that is > not contained in any Monticello package. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 21, 2009

[Pharo-project] Fwd: I have the following version of Seaside

by StÃ©phane Ducasse

Hi Fritz I think that some guys already answer that question in the pharo mailing-list I have to run now (kid business). Stef Begin forwarded message: > From: "Fritz Schenk" <Fritz_Schenk(a)Countrywide.Com> > Date: March 21, 2009 1:28:11 AM CEST > To: stephane.ducasse(a)inria.fr > Subject: I have the following version of Seaside > > > Smalltalk version 'Squeak3.9' > > Where do I get the latest pharo, and how do I install it on my image? > > Thanks > > ====================================================================== > Confidentiality Notice: The information contained in and transmitted > with this communication is strictly confidential, is intended only > for the use of the intended recipient, and is the property of > Countrywide Financial Corporation or its affiliates and > subsidiaries. If you are not the intended recipient, you are hereby > notified that any use of the information contained in or transmitted > with the communication or dissemination, distribution, or copying of > this communication is strictly prohibited by law. If you have > received this communication in error, please immediately return this > communication to the sender and delete the original message and any > copy of it in your possession. > ======================================================================

March 21, 2009

Re: [Pharo-project] I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

by Keith Hodges

Igor Stasenko wrote: > 2009/3/21 Keith Hodges <keith_hodges(a)yahoo.co.uk>: > >>> I think you have a full right to decide what [not] to include in Pharo. >>> Keith mentioned that you making many changes to many different parts >>> of system , which supposed to be maintained by original authour(s) or >>> currently active team(s), without giving a feedback or credit or >>> consulting with them about promoting such changes. >>> Okay, i think you're not stepping into other's domain.. it would be rude.. >>> But its going to be tricky, when you change the package X (not >>> maintained by anyone), from which depends a lot of work, which doing >>> in parallel by other team for package Y, which depends on X. >>> Here lies the problem, which can be solved by communicating with >>> people. Of course it requires the good will of both sides :) >>> >>> >>> >> Igor, >> >> I am not understanding your logic. >> >> You appear to be saying that if package X has got current maintainers, >> then it is not rude to make your own version of Package X. And that if >> you fork a package that has no maintainer then you will be in trouble. >> >> > > no, i meant package X having no maintainers and it should be ok to > make fork of it. > The trouble begins when another package - Y is maintained, but it depends on X. > What you suppose to do with such situation? > You mean the exact situation that many of us have been in for the past 3+ years! At a lower level, you have to have some kind of buffer package. Thats what Kernel-Extensions was for, it was the buffer covering the multitude of sins in the unmaintained Kernel. This can also be achieved with more intelligent installation tools that can install things according to rules "if this class is missing then apply this fix/changeset/package". (btw coincidentally (or not) Sake implements such rules in it's ClassTasks) That's what "Installer mantis ensureFix:" is all about, its a dumb way of acheiving the same goal. The next level up in intelligence is Installer-Scripts (which includes the current implementation of LevelPlayingField). It can install things specific to product/image version. (Pharo's ScriptLoader is somewhat equivalent, for pharo only.) If everyone who is maintaining packages A,B,C,Y that depends upon X, manages their fixes to X in a co-ordinated manner with tools such as Installer-Scripts, or Sake/Packages, this documents all use cases in detail. Then the future maintainer of X has simply to look at all of the package load definitions, and the list of fixes to his package that they require, his work is practically done for him. Please note that was also the explicit intention and purpose behind allowing Sake/Packages to be non-declarative if need be. If a user has to add a script to get a package to work in their specific context, then Sake/Packages is providing a knowledge capture service for the developer of X, showing exactly what is needed to get X working in all the contexts in which it has been applied. At a higher level, you need to consider architecting your code to be modular and to have interface/protocol definitions, and at the highest level you can consider doing interface/protocol negotiations, either statically (at package load time, or dynamically at run time. Statically is easiest - if they have version 1 of the database use interface A... etc, all of which Sake/Packages can do. For example I have written a number of modules for seaside28, called the "Client Framework", these will need to be reimplemented for Seaside29, but should still provide the same API. Dynamically is doable, but there is so much irrational feeling against use of #respondsTo: #askFor:, Null, and other facilities for making this work on a generic basis. For example Null needs to be in the kernel, because it must be maintained in sync with the kernel and IDE, otherwise the Kernel/IDE developers keep doing things which ruin Null's day. (stef please take note - I know you hate Null, but it is not intended to be a replacement for nil, it is most useful as a replacement for an entire missing interface on a macro scale) Going the other way, there is also help for maintaining a single package that can be deployed in muliple different contexts. The new PackageInfo in MC1.5 has more facilities for exporting a package, and deploying it in different contexts. For example, you can mark methods as "squeak only", "gemstone", "VW only" for example. So while you code and maintain "MyPackage" in your repository, when you save "MyPackage.squeak" it will filter out any vw only methods, or pharo only methods. When you save MyPackage.vw it will not include classes in MyPackage-Squeak. MyPackage.impl filters out the tests, and MyPackage.test saves the tests only. ...btw Igor in response to your other email about splitting up MC. MC1.5 has already been organised into categories for potential splitting up. For example separation of Model and GUI. The tests have already departed. The Monticello-Orphanage is intended to be unloadable. I was planning to split out the PasswordManager into a system project "System-Passwords". Keith

March 21, 2009

[Pharo-project] Rewriting an Input/EventSensor code

by Igor Stasenko

Hello lists, I making a cross-post, because there are interest from both camps to make it done :) Michael published a changesets with new event sensor code for Pharo, which mainly focused on supporting multiple event consumers(frameworks). Recently , we discussed it with Andreas, and had an idea to integrate this with Announcement framework (and Announcement will become a core package). I very like this idea, but i think we should discuss the implementation details before starting it. Here is my vision , how things should look like: - role 1. Event source. VM, is an events source, in most cases it is the only source, but not always. I would like to be able to plug-in a different event source.. imagine a remote socket connection, or previously recorded events and then replayed. So, an event source should be a separate, abstract entity, where VM is one of the concrete kind of it. There is also, sometimes a need to inject a fabricated events into event queue, to simulate user input, or for producing a synthetic events. - role 2. Event listener/Event sensor (or InputSensor) is a mediator between event source and higher level framework (Morphic.. etc), its role is to listen events from event source and then dispatch it to concrete consumer(s), if any. - role 3. Events. Events should be a full featured objects, with good protocol. A high level framework should not peruse with raw data, as it currently does with raw event buffers which coming from VM. This means, that changes will affect the Morphic. Morphic having a classes for user input events (keyboard/mouse) and decifering raw VM events into own representation. I think we should move the 'decifering' part to EventSource (sub)classes, and make sure EventSensor (and its consumers) dealing with full featured event objects, leaving event consumers free to decide what to do with them. - role 4. Event consumers. Note, there can be multiple different consumers, not just one, as its currently Morphic. We should make sure, that integration with any other framework will be painless. - be ready for supporting multiple host windows. This part is quite simple to do in EventSensor.. but not so simple in Morphic. One thing would be is to refactor all code which uses the Sensor global directly, and replace it with appropriate thing(s). But this is out of scope of event handling framework, at initial stage , we could keep things compatible with old ways (1 Sensor, 1 Display, 1 Morphic World). I started prototyping a classes for events, where each event kind having own event subclass, and directly decoding the VM raw event buffer, so then any event consumer(s) don't have to poke raw events. But since there were a good idea to make use of Announcements for it, it may need some refactoring. Michael, Andreas, i'd like to hear your comments and remarks, as well as any others are wellcome. -- Best regards, Igor Stasenko AKA sig.

March 21, 2009

Re: [Pharo-project] I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

by Igor Stasenko

2009/3/21 Keith Hodges <keith_hodges(a)yahoo.co.uk>: > >> I think you have a full right to decide what [not] to include in Pharo. >> Keith mentioned that you making many changes to many different parts >> of system , which supposed to be maintained by original authour(s) or >> currently active team(s), without giving a feedback or credit or >> consulting with them about promoting such changes. >> Okay, i think you're not stepping into other's domain.. it would be rude.. >> But its going to be tricky, when you change the package X (not >> maintained by anyone), from which depends a lot of work, which doing >> in parallel by other team for package Y, which depends on X. >> Here lies the problem, which can be solved by communicating with >> people. Of course it requires the good will of both sides :) >> >> > > Igor, > > I am not understanding your logic. > > You appear to be saying that if package X has got current maintainers, > then it is not rude to make your own version of Package X. And that if > you fork a package that has no maintainer then you will be in trouble. > no, i meant package X having no maintainers and it should be ok to make fork of it. The trouble begins when another package - Y is maintained, but it depends on X. What you suppose to do with such situation? > I am saying the opposite - that if you fork a package that has got > current maintainers, you > > a) insult the maintainers, > b) you undermine the progress that they may have made, > c) you undermine any efforts thay have made to build a team and > communication around that project. > d) you prevent future progress by the existing team > e) you make extra work for the exisiting team because you dont > communicate with them and they are forced to play catch up to you all > the time > f) you send out the message that volunteering to maintain any part of > the kernel is a hapless task, and will ultimately be a waste of time and > effort. > i agree with you on that.. just read my message more carefully :) > Keith > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

March 20, 2009

Re: [Pharo-project] Problem with senders?

by Mariano Martinez Peck

Sorry. No, it was not Algernon problem. I have a pharo0.1-10236dev09.02 but updated trougth: right button -> system update -> to 10256. Nothing more installed. I will put a ticket. Thanks, Mariano On Fri, Mar 20, 2009 at 8:07 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Sorry...It was totally my fault :( Sorry I nwas trying to run Algernon, > but it doesn't work :( > > I am algernon adict. > > I did this: > > Installer sm > update; > install: 'Algernon'. > Installer wiresong > project: 'ob'; > install: 'OB-Algernon'. > > > > > On Fri, Mar 20, 2009 at 7:48 AM, David RÃ¶thlisberger <squeak(a)webcitas.ch>wrote: > >> >> > I am trying to see the senders of a message. I select "startsWith:" in a >> > workspace -> right button -> extended search -> senders of it and I get >> > a wallback. >> >> I cannot reproduce this. >> What kind of image do you use? Looks like a pharo-dev; but which version? >> Did you update it manually to 10256? >> #of:label: is defined for a long time in OBNavigate; which version of OB >> have you loaded? >> >> David >> >> > MessageNotUnderstood: OBShowSenders class>>of:label: >> > 20 March 2009 1:11:08 am >> > >> > VM: unix - a SmalltalkImage >> > Image: Pharo0.1 [Latest update: #10256] >> > >> > SecurityManager state: >> > Restricted: false >> > FileAccess: true >> > SocketAccess: true >> > Working Dir /home/mariano/squeak/imagenes >> > Trusted Dir /home/mariano/squeak/imagenes/secure >> > Untrusted Dir /home/mariano/squeak/imagenes/My Squeak >> > >> > OBShowSenders class(Object)>>doesNotUnderstand: #of:label: >> > Receiver: OBShowSenders >> > Arguments and temporary variables: >> > aMessage: of: an OBSelectorNode label: 'Senders of >> > startsWith: [4]' >> > exception: MessageNotUnderstood: OBShowSenders >> class>>of:label: >> > resumeValue: nil >> > Receiver's instance variables: >> > superclass: OBNavigate >> > methodDict: a MethodDictionary(#browserClass->a >> > CompiledMethod (3617) #noChildr...etc... >> > format: 136 >> > instanceVariables: nil >> > organization: ('as yet unclassified' browserClass >> > noChildrenMessage) >> > >> > subclasses: nil >> > name: #OBShowSenders >> > classPool: nil >> > sharedPools: nil >> > environment: Smalltalk >> > category: #'OB-Standard-Announcements' >> > traitComposition: nil >> > localSelectors: nil >> > >> > DEVToolSet class>>browseSendersOf:name:autoSelect: >> > Receiver: DEVToolSet >> > Arguments and temporary variables: >> > aSymbol: #startsWith: >> > labelString: 'Senders of startsWith: [4]' >> > autoSelectString: 'startsWith:' >> > Receiver's instance variables: >> > superclass: StandardToolSet >> > methodDict: a MethodDictionary() >> > format: 2 >> > instanceVariables: nil >> > organization: ('as yet unclassified') >> > >> > subclasses: nil >> > name: #DEVToolSet >> > classPool: nil >> > sharedPools: nil >> > environment: Smalltalk >> > category: #ImageForDevelopers >> > traitComposition: nil >> > localSelectors: nil >> > >> > ToolSet class>>browseSendersOf:name:autoSelect: >> > Receiver: ToolSet >> > Arguments and temporary variables: >> > aSymbol: #startsWith: >> > titleString: 'Senders of startsWith: [4]' >> > autoSelectString: 'startsWith:' >> > Receiver's instance variables: >> > superclass: AppRegistry >> > methodDict: a MethodDictionary() >> > format: 2 >> > instanceVariables: nil >> > organization: ('as yet unclassified') >> > >> > subclasses: nil >> > name: #ToolSet >> > classPool: nil >> > sharedPools: nil >> > environment: Smalltalk >> > category: #'System-Applications' >> > traitComposition: nil >> > localSelectors: nil >> > registeredClasses: an OrderedCollection(StandardToolSet >> > OTToolset DEVToolSet) >> > default: DEVToolSet >> > >> > SystemNavigation>>browseSendersOf:name:autoSelect: >> > Receiver: a SystemNavigation >> > Arguments and temporary variables: >> > aSelector: #startsWith: >> > labelString: 'Senders of startsWith:' >> > autoSelectString: 'startsWith:' >> > title: 'Senders of startsWith: [4]' >> > size: 4 >> > senders: an OrderedCollection(a MethodReference Algernon >> >> > #isMatchingClass:gi...etc... >> > Receiver's instance variables: >> > browserClass: nil >> > hierarchyBrowserClass: nil >> > >> > >> > --- The full stack --- >> > OBShowSenders class(Object)>>doesNotUnderstand: #of:label: >> > DEVToolSet class>>browseSendersOf:name:autoSelect: >> > ToolSet class>>browseSendersOf:name:autoSelect: >> > SystemNavigation>>browseSendersOf:name:autoSelect: >> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> > SystemNavigation>>browseAllCallsOn: >> > [] in TextMorphForShoutEditor(ParagraphEditor)>>sendersOfIt {[self >> > systemNavigation browseAllCallsOn: aSelector]} >> > TextMorphForShoutEditor(Controller)>>terminateAndInitializeAround: >> > TextMorphForShoutEditor(ParagraphEditor)>>sendersOfIt >> > [] in PluggableShoutMorph(PluggableTextMorph)>>sendersOfIt {[textMorph >> > editor sendersOfIt]} >> > [] in PluggableShoutMorph(PluggableTextMorph)>>handleEdit: {[result := >> > editBlock value]} >> > TextMorphForShout(TextMorph)>>handleEdit: >> > PluggableShoutMorph(PluggableTextMorph)>>handleEdit: >> > PluggableShoutMorph(PluggableTextMorph)>>sendersOfIt >> > UndefinedObject(Object)>>perform:orSendTo: >> > [] in ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: >> > {[(selArgCount := selector numArgs) = 0 ifTrue: [target perform: >> > selector] ...]} >> > BlockContext>>ensure: >> > CursorWithMask(Cursor)>>showWhile: >> > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: >> > ToggleMenuItemMorph(MenuItemMorph)>>mouseUp: >> > ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp: >> > MouseButtonEvent>>sentTo: >> > ToggleMenuItemMorph(Morph)>>handleEvent: >> > MorphicEventDispatcher>>dispatchDefault:with: >> > MorphicEventDispatcher>>dispatchEvent:with: >> > ToggleMenuItemMorph(Morph)>>processEvent:using: >> > MorphicEventDispatcher>>dispatchDefault:with: >> > MorphicEventDispatcher>>dispatchEvent:with: >> > ...etc... >> > >> > >> > ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

March 20, 2009

Re: [Pharo-project] I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

by Keith Hodges

> I think you have a full right to decide what [not] to include in Pharo. > Keith mentioned that you making many changes to many different parts > of system , which supposed to be maintained by original authour(s) or > currently active team(s), without giving a feedback or credit or > consulting with them about promoting such changes. > Okay, i think you're not stepping into other's domain.. it would be rude.. > But its going to be tricky, when you change the package X (not > maintained by anyone), from which depends a lot of work, which doing > in parallel by other team for package Y, which depends on X. > Here lies the problem, which can be solved by communicating with > people. Of course it requires the good will of both sides :) > > Igor, I am not understanding your logic. You appear to be saying that if package X has got current maintainers, then it is not rude to make your own version of Package X. And that if you fork a package that has no maintainer then you will be in trouble. I am saying the opposite - that if you fork a package that has got current maintainers, you a) insult the maintainers, b) you undermine the progress that they may have made, c) you undermine any efforts thay have made to build a team and communication around that project. d) you prevent future progress by the existing team e) you make extra work for the exisiting team because you dont communicate with them and they are forced to play catch up to you all the time f) you send out the message that volunteering to maintain any part of the kernel is a hapless task, and will ultimately be a waste of time and effort. Keith

March 20, 2009

Re: [Pharo-project] I need some advice (was Re: [squeak-dev] Organising and Documenting Micro-Universes in Squeaksource)

by Keith Hodges

StÃ©phane Ducasse wrote: > Geeeee. > > MC is not any project, it is our key infrastructural element. So we > must control it. > I disagree, its key to all users of squeak. So you must ensure that it is looked after and maintained. There is absolutely no need to control it. You can control it by contributing to it and participating in its future development. By competing you kill it, and you are killing it stone dead, because no one can add a feature without being held back by the users of the other fork(s). > But of what are you talking? That you introduced traits support and > atomic loading on MC > and that we do not consider it? But you know several people privately > asked us not to > include your code. What kind of people are you working with? How rude can people get? This is open source for goodness sake. You aint paying for this stuff, on the contrary, its costing me a fortune. I have a 1977 camper van that I am currently restoring, someone once said to me "anything you do to it, will be an improvement", well that was the state of MC1.0. It's about teamwork, and merging of talents. I never said I was qualified to take on maintenance of MC, I never wanted to do it. The fact is that MC1 is unusable, and someone had to fix it. The future of MC depends entirely upon the contribution of a team of people, but your attitude and the attitude of these myopic individuals precludes it, because none of you will contribute to the team effort required. You have a community full of people who write great code and dont write a single class comment, and yet their often unusable contributions are accepted without being completely insulted! > So we pay attention. > Those people have not contributed to MC either therefore their input is completely mute and irrelevant. I have said many times before, the code is not relevant it is the attitude that is important. If you dont like the code then the repo is open to fix it, and the forums are available to comment on it. Some people have found their feedback incorporated within the hour! People who cant be bothered to offer feedback or participate, have no right to criticise. Ok the tests are not up to scratch, I cant help it if whoever wrote the tests made them incomprehensible. When lukas loaded MC1.5 an installation error didnt completely unload the previous version of MC1 then he complained that there were lots of unsent messages. I don't have time to work on MC1.5 anymore, so those who say "dont use keiths code", are sending a huge message to anyone who cant make a perfect contribution to the community not to bother, your contribution will be discarded. > When I took the time to give feedback on kernel extensions or rio this > But you never even understood what the reason behind kernel-extension was, you criticised it and refused to use anything that depended on it, because it wasn't perfectly what you wanted, and it contained method overrides. That was the whole point, it was supposed to contain method overrides. If you put all of the method overrides for the kernel in one place, then multiple overlapping method overrides from different packages do not occur, there will be no conflicts. Having them in Kernel-Extensions gives you a place to manage them and participate in the discussion over what would be accepted or not. You didn't really participate in that discussion, you simply said things along the line of Kernel-Extensions includes Null therefore we dont like it, full stop. Again you threw the baby out with the bath water. When I stopped using Kernel-Extensions, and started using changesets to publish exactly the same code without method overrides, all of a sudden the same code became magically acceptable! You might be interested to know that more than 80-90% of what was Kernel-Extensions has already been added to pharo, so there wasnt so much wrong with it after all. > Do you think that I'm rude because I reply to you or when I do not > reply? > > Its got nothing to do with replying or not. Its all to do with your team having the expertise to get SystemEditor working with Traits, for the good of all, but instead you spend time and effort forking MC, for the good of yourselves, and in the process trash a lot of time and effort expended for your benefit. Its to do with your team forking SUnit unnecessarily etc etc >> I consider the attitude conveyed by the words "No but we have the >> right >> to choose and consider if we like it or not." to be tantamount to >> snobbery, > You saw how we worked with the settings and preference discussion with > alain. > So Alain is external to your team? He had the courtesy of discussing the preferences ideas with the wider community, and for that I thanked him, and added him to my "non-rude" list. > I do not ask for that. I do not see why I would have the right to come > and change > think in your project. > > >> It is perfectly possible for the following projects to be initiated as >> loadable modular sub-projects, developed with an ethos of >> participation >> for anyone to contribute and for anyone to use. >> >> 1. Registration for menus and UI features >> 2. Improvements to Streams >> 3. HTTPSocket >> 4. Alternatives to Changesets >> 5. Replace the changes file mechanism with something else >> 6. Atomic loading (including traits) >> 7. Replacements for Morphic, MVP >> 8. Compiler >> 9. Network. >> 10. Compression. >> 11. Files >> 12. SSpec >> 13. SUnit >> 14. Code Browsers/Tools >> > > Probably. Now if we do not like the code quality we will not use that. > This has nothing with snobbery this has to do with credibility on the > long run. > Hang on... this is a list of projects, most of which dont have any code yet, and you are talking about rejecting stuff that doesnt meet your standards! That's exactly what I mean. If you spec out a project, plan it, and "contribute" to the team that works on it, then it will meet your standards by definition. Therefore there is no need to prejudice anything with such comments as "if 'their' work its not up to 'our' standards". That's my whole point, you get the standards you want by participating in the process, not by looking down your nose at the contributions being hacked by some poor old stressed out full time carer. >> I am seriously considering licencing Rio under something other than >> MIT, >> so that you cant use it, until you change your attitude towards your >> potential benefactors. >> > > Do it if you need, we will just not use it. > Note that some people do not like rio design, so the fact that it is > MIT does not mean that > These "some people", are more folks who have never sent me a single email discussing the design. And by the way Rio has had three complete redesigns since it was first written, incorporating various feedback and ideas. Thankfully I have "some emails" from "some people" who like it Keith

March 20, 2009

Re: [Pharo-project] How to rename a package ?

by Lukas Renggli

> For me I see that more as a menu to rename a package :) The script does not rename a package. It just lists the code that is not contained in any Monticello package. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 20, 2009

[Pharo-project] Problem with cdelc and apicall

by Mariano Martinez Peck

People: I am having a problem with cdelc and apicall in windows with SqueakDBX. I have a abstract class OpenDBX with the subclasses: OpenDBXWin32 and OpenDBXUnix. SqueakDBX detects which OS you are using and instances one of them. They have these methods: OpenDBXWin32: apiBind: handle database: databaseName name: userName password: password method: method "int odbx_bind(odbx_t* handle, const char* database, const char* who, const char* cred,int method )" <apicall: long 'odbx_bind' (ulong char* char* char* ulong) module: 'libopendbx-1.dll'> ^self externalCallFailed OpenDBXUnix: apiBind: handle database: databaseName name: userName password: password method: method "int odbx_bind(odbx_t* handle, const char* database, const char* who, const char* cred,int method )" In linux, I don't have problems, but in windows, when I try to download it from MC, I have a "sintax errror" "OpenDBXUnix api calls apiBind: handle database: databaseName name: userName password: password method: method" apiBind: handle database: databaseName name: userName password: password method: method "int odbx_bind(odbx_t* handle, const char* database, const char* who, const char* cred,int method )" <> expected ->cdecl: long 'odbx_bind' (ulong char* char* char* ulong) module: 'opendbx'> ^self externalCallFailed <cdecl: long 'odbx_bind' (ulong char* char* char* ulong) module: 'opendbx'> ^self externalCallFailed Does anyone have an idea of what can be happening ? thanks in advance. Mariano

March 20, 2009