August 2016 - Pharo-users - lists.pharo.org

UFFI const, unsigned, opaque-ish types
by Ben Coman Sept. 1, 2016

Sept. 1, 2016

For this definition pulled from a library header file... typedef struct { const void *data; unsigned private_flags; } CXString; which is used with a helper function to get a usable string like... void show_clang_version(void) { CXString version = clang_getClangVersion(); printf("%s\n", clang_getCString(version)); clang_disposeString(version); } ==> 'Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM 3.5.0)' So I defined... FFIExternalStructure subclass: #CXString instanceVariableNames: '' classVariableNames: '' package: 'LibCLang' and ignoring the const as advised in the manual [1], I try... CXString class >> fieldsDesc ^ #( void *data; unsigned private_flags; ) but... CXString rebuildFieldAccessors. ==>Error: Unable to resolve external type: unsigned I also tried "unsigned int private_flags;" but get the same error. Any ideas what is wrong? Actually I can kind of ignore creating accessors since this is like an opaque type where I'm not expected to access its internals, but I do need CXString as a return value like this... LibCLang class >> getClangVersion ^ self ffiCall: #( CXString clang_getClangVersion () ) module: LibCLang which needs to be passed to this function to get a workable string.... LibCLang class >> getString: aCXString ^ self ffiCall: #( String clang_getCString ( CXString aCXString ) ) module: LibCLang However this doesn't work if I use FFIOpaqueObject instead of FFIExternalStructure. I guess the difference is opaque objects are normally pointers to a type, whereas here that pointer is contained in a struct. What I've done at the moment to push ahead with experimenting is avoid needing to generate accessors by adding... CXString >> printOn: asStream self getString printOn: aStream CXString >> getString ^ self ffiCall: #( String clang_getCString ( CXString self ) ) module: LibCLang such that... LibCLang getClangVersion "<Print It>" ==> 'Debian clang version 3.5.0-10 (tags/RELEASE_350/final) (based on LLVM 3.5.0)' Is there a better way to approach this? cheers -ben btw, this is in Pharo 5 (Moose 6). [1] https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre…

2 3

BitArray and BooleanArray ?
by Bernardo Ezequiel Contreras Sept. 1, 2016

Sept. 1, 2016

Hi, why there isn't a BitArray or BooleanArray in the collection library? is there a sustitute for that? thanks -- Bernardo E.C. Sent from a cheap desktop computer in South America.

3 2

Re: [Pharo-users] [Garage] How to espace sql special chars in a query?
by Blondeau Vincent Aug. 31, 2016

Aug. 31, 2016

Hello, I used some method of RAEscapingSqlPrinter to escape the quotes. And it is working nicely now. I added the escaping method in Garage: String >> asPostgresEscapedSql You have to call it on the "unsafe strings" before executing the query (prepared statement or not). Thanks Pierce! Cheers, Vincent > -----Message d'origine----- > De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de > Pierce Ng > EnvoyÃ© : vendredi 12 aoÃ»t 2016 17:44 > Ã : Any question about pharo is welcome > Objet : Re: [Pharo-users] [Garage] How to espace sql special chars in a query? > > On Fri, Aug 12, 2016 at 01:36:21PM +0200, Blondeau Vincent wrote: > > > Which database? > > Postgres > > PostgresV2 driver does not support the PostgreSQL extended query protocol > which allows prepared statements, AFAIK. > > https://www.postgresql.org/docs/current/static/protocol-overview.html. > > As for escaping SQL, the ROE package has a class called RAEscapingSqlPrinter > which may help. > > http://smalltalkhub.com/#!/~PharoExtras/ROE > > Pierce !!!************************************************************************************* "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"

1 0

The myth of a small deployment image using metacello
by Norbert Hartl Aug. 31, 2016

Aug. 31, 2016

I have a seaside project that will be installed in a typical fashion headless on a server somewhere on the net. The project is in its final stage so I started to care about the size of the image. Or better: The size of the image is not my main concern but the number of packages installed. The less packages you load the better it is, it is that simple. This time I encountered a problem that I often see but this particular one explains in a very good way that how we use metacello can be improved. In my project I load only Seaside-Core. This has the advantage of loading far less packages and I don't have the need to remove a bunch of registered web applications that registered themselves when being loaded. I make use of a bootstrap template bought somewhere on the net. I use magritte a lot so I was happy to see that there is a package called BootstrapMagritte. The package extends some magritte ui classes and overwrites some methods to add specific classes to HTML tags. Basically not very much code. What happended after I added the package as a dependency to my own project you can see here in the load directive of metacello linear load : explicit load : 0.2.3 [ConfigurationOfBootstrapMagritte] linear load : 0.2.3 [ConfigurationOfBootstrapMagritte] linear load : 3.5.0 [ConfigurationOfMagritte3] linear load : 1.1.0 [ConfigurationOfMagritteGlamourForPharo40] load : Glamour-Presentations.issue_1126-SeanDeNigris.178 load : Glamour-Morphic-Renderer.issue_1126-SeanDeNigris.325 explicit load : 3.1.5 [ConfigurationOfSeaside3] linear load : 3.1.5 [ConfigurationOfSeaside3] explicit load : 0.26 [ConfigurationOfParasol] linear load : 0.26 [ConfigurationOfParasol] linear load : 3.2.0 [ConfigurationOfSeaside3] load : Seaside-Tests-REST-Core-EstebanMaringolo.34 This is wrong in so many ways. I load a little extensions to my web application and end up loading _all_ of seaside which loads beach parasol (a ui testing framework), _all_ of magritte which in turn loads glamour packages (a ui toolkit). So at this point I think WTF? Why does this happen? Because the "default" group in many projects contains all of the packages and dependencies of the project. I thought at first this is wrong but in the meantime I think it is right. Whenever a configuration is loaded without additional parameters the "default" group gets loaded. This is the best scenario for newcomers (e.g. using the catalog to load). They don't know better but want to see what the package has to offer. Fine, we should support that. For managing projects this gets annoying really quick like you can see above. It would always load all dependencies and all packages of every project that your own project depends. This is a no-go. To circumvent this a lot of people add a "core" group to their configurations (loading the essential parts). This is great because in my own project I can add a dependency to a project and load only the "core" group. This works if the dependency chain is not very long (at best it works in depth 1 ;) ). As soon as a project has two interesting groups the problem gets worse. A good example is magritte. It is useful for describing your model as well as it contains useful seaside components. The moment I add a dependency from my model package to magritte seaside I know it is wrong. I find myself sometimes duplicating dependencies just to mitigate the effect. I do something like project: 'Magritte3Seaside' with: [ spec className: #ConfigurationOfMagritte3; versionString: #'stable'; loads: #('Seaside' ); repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' ]; project: 'Magritte3Core' with: [ spec className: #ConfigurationOfMagritte3; versionString: #'stable'; loads: #('Core' ); repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' ]; andâ¦ package: #'MyProject-Model-Core' with: [ spec requires: #( 'Magritte3Core' ). ]; package: #'MyProject-UI-Core' with: [ spec requires: #( 'Seaside3' 'Magritte3Seaside' 'BootstrapMagritte' ). ]; just to be able to put the right dependencies. But this way is cumbersome to do and not support by tools like Versionner. The main problem to me is that the maintainer of the configuration defines the granularity of pieces to load forcing me to do stupid workarounds to achieve what I want. To me the problem is that the separation is not done properly. I think the logic of having loads() in the baseline and a pure string like "Magritte3Core" in the dependency spec is reversed. It should be project: 'Magritte3' with: [ spec className: #ConfigurationOfMagritte3; versionString: #'stable'; repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' ]; andâ¦ package: #'MyProject-Model-Core' with: [ spec requires: #( 'Magritte3:Core' ). ]; package: #'MyProject-UI-Core' with: [ spec requires: #( 'Seaside3' 'Magritte3:Seaside' 'BootstrapMagritte' ). ]; Note the "Magritte3:Core" in the dependency spec. The meaning is that there is a dependency to Magritte3 and group Core. This way dependencies can be properly aligned. Or are there other way to deal with it? What do you think? Norbert

4 4

Spec Label is Black on Dark theme
by Brad Selfridge Aug. 31, 2016

Aug. 31, 2016

How does one change Spec labels so that they don't show as black on Dark Theme but do show as black on standard Pharo theme? ----- Brad Selfridge -- View this message in context: http://forum.world.st/Spec-Label-is-Black-on-Dark-theme-tp4913253.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

4 3

GTPlayground status: open or close
by Federico.Balaguer Aug. 31, 2016

Aug. 31, 2016

Hello, BotArena is a tool for teaching objects that we are using in my University. The tool allow students to enter Smalltalk expressions using an instance of GTPlayground. There is a "reset" scenario where BotArena needs to know if there is a Playground open so it does refresh bindings to given objects. So how can someone check whether a Playground is open or closed? Thanks! Federico -- View this message in context: http://forum.world.st/GTPlayground-status-open-or-close-tp4913257.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

2 2

standalone/runtime executable
by Gour Aug. 30, 2016

Aug. 30, 2016

Hello, there are some Smalltalks like Dolphin, VisualWorks..which can, afaict, create stand-alone executable for easier deployment to end users. I'm aware that Pharo probably has more important tasks to tackle first, but just curious if creating stand-alone/runtime exectuables is somewhere on its radar? Sincerely, Gour -- As a lamp in a windless place does not waver, so the transcendentalist, whose mind is controlled, remains always steady in his meditation on the transcendent self.

9 19

Traits inheritance
by Petr Fischer Aug. 29, 2016

Aug. 29, 2016

Hello, is Trait methods inheritance supported in Pharo? Like this: TBaseTrait>>myMethod self subclassresponsibility TSubTrait uses: TBaseTrait ... TSubTrait>>myMethod some real implementation MyClass uses: TSubTrait (MyClasss>>myMethod already implemented in TSubTrait, but I can reimplement again) Problems: 1) when I put "self subclassresponsibility" in TBaseTrait, everything is nicely visible in Nautilus browser (something like "abstract" method with proper (a) yellow icon). But I read somewhere, that for traits, I must use "^ self explicitRequirement" instead of "subclassresponsibility" - then, I can't see anything usefull in Nautilus 2) sometimes (it was maybe with "self subclassresponsibility" in TBaseTrait), Monticello not detected overrided TSubTrait>>myMethod (TSubTrait residing in another package than TBaseTrait) and this overrided trait method in TSubTrait was not saved in monticelo package (no changes was detected by Monticello, thus not saved to mcz package!) So - is trait a "bag of methods" only, or is trait inheritance supported? Thanks very much! pf

3 5

More reliable VCS, Project management and tools?
by Vitor Medina Cruz Aug. 29, 2016

Aug. 29, 2016

Hello, I am doing some katas and challenges using pharo 5, and I got a bad impression from the VCS and Project management as a whole. I got a bunch of problems with, as it seems to me, simple stuff, and so I loose a lot of confidence with the system :( I get myself saving the image a lot and double checking anything done with version control. I am going to tell more or less what I have done in the last days for you to get an idea of the problems I had and then ask some questions. I am using Pharo 5 in a Windows 10 system and I was first trying to use GIT as the underlying provider for monticello. I know gitfiletree has problems in a windows system, but I tried to use it anyway to see what happens and I got an image unusable, with Nautilus package view messed up with red blocks and yellow crosses.... scary. I am not sure if that problem with Nautilus was actually caused by gitfiletree since I changed the package of the configuration of my project (I did that only to see if I could) and then rolled that back while testing gitfiletree... but, well, gitfiletree do not work on Windows, I got an index out of bounds exception or something like that, so I gave up and used filetree with a git client to make actual commits. However, for anyone to load my configurations and projects, I could not use filetree with a local directory, so I created a smalltalkhub repository and started to commit there and on my local filetree directory. I used Kommiter to commit onto smalltalkhub and Monticello to copy changes to my local file tree until I got and error using Komiter. I tried to proceed instead of abort and one of the packages didn't commit correctly. Trying to access it on the smalltalkhub site I got an error.... I opened Monticello and had to Flush Cached Version so that it stopped to tell me that there were no changes and started to prompt an error message. I had to forcibly save a new version so that it work again. If I go now to smalltalkhub, sometimes I got errors, sometimes don't. I don't know yet if the error was with komiter, smalltalkhub or my image. Oh, and Monticello sometimes says there are changes to pakages that I haven't changed, when I click on changes it discover that there are no changes and remover the "*" mark of it. I tried using Versioner too, but sometimes when I try to commit a minor version, for example, the system hangs and I need to "Alt + .". For now the reliable way of using versioner is to create a release version and commit from Monticello Right now I fell like stepping in a land mine, so I would like to know: 1- Shouldn't I be using Windows? Pharo isn't stable on a Windows plataform? 2- Is Komiter reliable or should I use Monticello directly? 3- Is Smalltalkhub reliable or should I use other repository? 4- I don't believe those problems are normal, otherwise there wouldn't be so many places using Pharo for production purpose, any hints of what I may be doing wrong? :( Thanks in advance and sorry if the stuff I am doing seems dumb... :( Regards, Vitor

4 4

[ann] GTExamples alpha
by Tudor Girba Aug. 28, 2016

Aug. 28, 2016

Hi, Over the last coupe of years Stefan Reichhart and the rest of the GT team worked on an implementation of examples. The work is inspired from previous work done by Markus Gaelli and Adrian Kuhn. As one of the goals of GT is to offer a live programming environment, one important issue is how to move from the static code to live objects as fast as possible. That is why we worked on this library as a solution to provide a link between the static code and live objects. Furthermore, this examples library also enables the definition of assertions on the examples, and this provides the possibility of rethinking the way we construct tests throughout our system. Tests are great as they help us create live objects and then to assert live properties. However, they do not allow us to leverage the objects we create, and this can be a tremendous resource for understanding systems. In our vision, examples should be everywhere and they should be explicitly linked to the static code they exemplify. That is why the library comes with an initial integration in existing tools (such as Nautilus, Spotter, Inspector). The current solution works well and it is the result of several rewrites. We think that the solution is complete in terms of features, but there are still several things to improve and iterate on. To this end, I kindly ask you to take a look at it while distinguishing between the concrete implementation choice (e.g., the current extensive use of pragmas) and the conceptual benefits of the approach. To ease the discussion, we put together a short documentation: http://gtoolkit.org/doc/Examples/examples.html That being said, you can get it with the full GToolkit in Pharo 6.0: http://gtoolkit.org/#install (easiest is to download the ready made image for now) For those that are at ESUG, I will try to provide a short overview during the Show Us Your Project session from today. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

2 5