April 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 5445: Broken command-line arguments in 1.4

by StÃ©phane Ducasse

Thanks michael BTW esteban will work on the debugger bugs :) Stef On Apr 7, 2012, at 2:33 PM, Michael Roberts wrote: > Hi, i tested the fix in 1.4 and it seemed to work fine. > > http://code.google.com/p/pharo/issues/detail?id=5445 > > > thanks, > Mike >

April 7, 2012

Re: [Pharo-project] [ANN] NBOpenGL update

by StÃ©phane Ducasse

On Apr 7, 2012, at 1:12 PM, Igor Stasenko wrote: > On 7 April 2012 09:09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Igor >> thanks a lot. >> Did you define a stable version because like that we can publish it to the MetaReportForPharo14 and >> use the browser to load it. >> > i never publish broken metacello versions.. > if something is broken in version i fixing it instead of releasing new > metacello version. What I want to say is that I imagine that the configuration browser load a configu and load automatically #stable so if you do not define #stable but a version may be it does not load. But may be I'm wrong I did not check the code of the browser. Stef > >> Stef >> >> On Apr 6, 2012, at 3:31 PM, Igor Stasenko wrote: >> >>> Hi there, >>> >>> for those, who interested, i updated a NBOpenGL configuration. >>> >>> Changes are: >>> >>> - updated GL API to most recent available (taken directly from opengl >>> specs). Now there is about 300 more methods to explore :) >>> - finally dealt with win32 support code and made it working again >>> - fixed the GLX function prefix , which should be 'glX' not 'glx' >>> >>> To load it in 1.4 use: >>> >>> Gofer new >>> squeaksource: 'NBOpenGL'; >>> package: 'ConfigurationOfNBOpenGL'; >>> load. >>> >>> >>> and then >>> >>> (ConfigurationOfNBOpenGL project version: '1.0.2') load >>> >>> I did not tested the update thoroughly.. so i would appreciate if >>> people will try it out and tell how it goes. >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > > -- > Best regards, > Igor Stasenko. >

April 7, 2012

Re: [Pharo-project] [update 1.4] #14421

by Mariano Martinez Peck

Congrats for your first integration!!! :) On Wed, Apr 4, 2012 at 4:47 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > 14421 > ----- > > Issue 5534: Do we rename/sync FS for 1.4? > http://code.google.com/p/pharo/issues/detail?id=5534 > > (first one :) > > -- Mariano http://marianopeck.wordpress.com

April 7, 2012

Re: [Pharo-project] Bind variables in statements & procedures

by Mariano Martinez Peck

On Fri, Apr 6, 2012 at 10:43 PM, kromakey <recursive68(a)gmail.com> wrote: > Hi, > > I've been looking at the DBTalk tests/examples and also at OpenDBX, > and it looks like binds variables aren't supported in SQL statements > and more importantly for myself when using them in procedures. > > In Java's JDBC: > > String sqlStmt = "SELECT * FROM employees where > last_name=? and > first_name like ?"; > prepStmt = conn.prepareStatement(sqlStmt); > prepStmt.setString(1, bindvarLastName); > prepStmt.setString(2, bindvarFirstName); > rs = prepStmt.executeQuery(); > > In Perl DBI you can do this when using Oracle PL/SQL, which allows you > to get return values from the procedure using bind variables in this > case $message and $status, when call a PL/SQL procedure: > > # bind variable > $message = undef; > $status = undef; > > # prepare query > my $sth = $dbh->prepare( > "BEGIN > test.testProc(:status, $username,:message); > END;" > ); > $sth->bind_param_inout(":status", \$status, 10); > $sth->bind_param_inout(":l_message", \$message, 500); > > # execute query > $sth->execute; > > > It looks like this is a limitation of OpenDBX rather than DBXTalk, Unfortunatly, yes, I think it is a limitation of OpenDBX. At least it was planned: "Prepared statement interface" in http://www.linuxnetworks.de/doc/index.php/OpenDBX/Future > but > if it is the case it's a big omission when you compare it against > other languages database interface APIs, such as Java's JDBC, Perl's > DBI and Python cx_Oracle for example. This is also not so good from a > security perspective as bind variables are one of the recommended > defences against SQL injection attacks. > For that we have: http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/odbx_escape > > Am i correct in thinking this, or I have I missed something ? > Sorry for the bad news, but I think you are correct. -- Mariano http://marianopeck.wordpress.com

April 7, 2012

[Pharo-project] Issue 5445: Broken command-line arguments in 1.4

by Michael Roberts

Hi, i tested the fix in 1.4 and it seemed to work fine. http://code.google.com/p/pharo/issues/detail?id=5445 thanks, Mike

April 7, 2012

Re: [Pharo-project] [ANN] NBOpenGL update

by Igor Stasenko

On 7 April 2012 09:09, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Igor > thanks a lot. > Did you define a stable version because like that we can publish it to the MetaReportForPharo14 and > use the browser to load it. > i never publish broken metacello versions.. if something is broken in version i fixing it instead of releasing new metacello version. > Stef > > On Apr 6, 2012, at 3:31 PM, Igor Stasenko wrote: > >> Hi there, >> >> for those, who interested, i updated a NBOpenGL configuration. >> >> Changes are: >> >> - updated GL API to most recent available (taken directly from opengl >> specs). Now there is about 300 more methods to explore :) >> - finally dealt with win32 support code and made it working again >> - fixed the GLX function prefix , which should be 'glX' not 'glx' >> >> To load it in 1.4 use: >> >> Gofer new >> Â squeaksource: 'NBOpenGL'; >> Â package: 'ConfigurationOfNBOpenGL'; >> Â load. >> >> >> and then >> >> (ConfigurationOfNBOpenGL project version: '1.0.2') load >> >> I did not tested the update thoroughly.. so i would appreciate if >> people will try it out and tell how it goes. >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

April 7, 2012

[Pharo-project] GSoC news: we got 30 proposals, few stats

by Janko MivÅ¡ek

Dear Smalltalkers, Yesterday passed a deadline for students to propose how will they do the projects and we received 30 proposals from 23 students, which is in my opinion quite a nice number and I'm sure we can end up with quite a number of nice projects this year. And what is even more important: new Smalltalkers in community! Next two weeks mentors will review and rank/vote for the proposals, Google will give us a number of stipendiums it will provide and in few days after Friday 20.April we will have a final list of accepted students and their projects. Few stats (numbers of all participating): 32 projects 34 mentors 32 students 30 proposals 23 students wrote proposal Students by Smalltalk skill: 11 None 9 Low 5 Medium 7 High Students from countries: 5 Argentina 5 India 4 Russia 3 USA 2 Chile 2 Czech Republic 2 Malaysia 1 China 1 Croatia 1 Ecuador 1 Egypt 1 France 1 Germany 1 Sweden 1 Ukraine 1 Slovenia Stay tuned! Janko @ Carla -- Smalltalk GSoC Admin Team http://gsoc2012.esug.org

April 7, 2012

Re: [Pharo-project] Why do we have classOrganizer and BasicClassOrganizer?

by Craig Latta

> Ideally I want to remove categories because they are redundant with > package and they should be managed as class tags. Hear hear. -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547 + 1 510 282 7468

April 7, 2012

Re: [Pharo-project] Why do we have classOrganizer and BasicClassOrganizer?

by StÃ©phane Ducasse

Ideally I want to remove categories because they are redundant with package and they should be managed as class tags. > On Fri, Apr 6, 2012 at 10:30 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 6 April 2012 20:07, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > On Fri, Apr 6, 2012 at 6:59 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> > >> On 6 April 2012 16:53, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > >> > BasicClassOrganizer has no users... Is it there for any purpose? > >> > > >> > What about joining them? > >> > > >> > >> Ehh... i was also looked at those classes couple years ago and > >> wondered why if its really worth > >> having so complex implementation to save few bytes of space.. > >> > >> I would rewrite this stuff and leave just a Categorizer with clean > >> protocol and structure: > > > > > > yes > > > >> - categorizer holds categories (order could be important, but i would > >> just keep it unspecified , i.e, > > > > > > yes. I was working in a simple version having #sort:, #sortAlphabetically, > > #sortByAmmountOfElements > > > >> > >> instead > >> OrderedCollection ( categoryName -> {.. category items .. } ) > >> > >> I would use Dictionary > >> #categoryName -> Set(items) > > > > > > I'd like having a Category object there. > > > >> > >> > >> this class should serve basic operations like adding /removing and > >> queries: > >> - what is a categor(ies) of element (if element can be include only > >> into single category at once) > >> - what are category names > >> - what are elements of specific category.. > >> Period. > >> And it actually can serve as a general categorizer (not just for > >> classes/packages). > > > > > > but then we have to put the changes announcements/notifications in another > > place > > > yes. of course. > usually operations are logged by separate entity than in place where > it actually happens. > you recording some operation over some model, and model don't > necessary needs to know > that you recording, isn't? > > I'm with you :), was just remarking one implication of the change. And thinking that way makes the change much more aggressive :P. But I know, step by step... > > > >> > >> > >> The way how BasicClassOrganizer using inheritance is abuse.. > >> since it extends a clean concept (Categorizer) with unrelated stuff, > >> like classComment and commentStamp. > > > > > > Ok, you are making me open an issue to move those to class :). 1.5? > > > >> > >> Class organizer, should instead delegate, or even better, Class > >> should use two different fields for categories and class comment.. > >> but not mixing everything into one pile of mess. > >> > >> > Guille > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > -- > Best regards, > Igor Stasenko. > >

April 7, 2012

Re: [Pharo-project] SmallLint and manifest

by StÃ©phane Ducasse

Thanks > Hi, > > Thanks. > > I gave it a short try, and here are some comments: > - The Manifest-Core should contain only the core of the manifest engine. For example, I see here some mechanism for traversing Manifest classes and retrieving data from them. Everything else that is specific to SmallLint should be in a Manifest-SmallLint package. > - All tests should be in the Manifest-Tests package (currently, there are extension tests in Manifest-Core - I actually do not know why) > - I like it that a Manifest class does not have to inherit from a specific root class. > - There exists a ManifestManifestCore class, but I do not understand why there are subclasses to it. > - You are using numbers to identify SmallLint rules. For this, you extended the rules with unique numbers. This is a very brittle scheme, and when people have domain specific rules, you will likely get a mess. Furthermore, I do not see the reason for having a number as a unique identifier, when you already have a unique identifier in the name of the rule class. Also, when looking at a method, we see something like: rule17V1FalsePositive. This is unnecessary cryptic. Because we do not want to rely on class refactoring. > - In the rule methods, you are storing strings. This means that when someone renames a rule, the code in there will not be updated. Why not store this information as normal code and use symbols that can be queried? I do not get it? It is normal code no? You mean symbols instead of strings. We will the issues. > > Cheers, > Doru > > > > On 6 Apr 2012, at 09:51, Simon Allier wrote: > >> Hi pharoers >> >> Since a couple of months the Pharo team has been working on improving the support for rules checking and in particular the handling of false positives (there is nothing more boring that to get all the time the same warnings that we know are not adequate). >> We added a manifest mechanism to manage the false/true positive of SmallLint, the rule checker of Pharo. A manifest is a class that contains meta data. In the future we may add package license and package documentation. This data is stored in methods on the meta side of the class. So, manifest can be versioned in Monticello and not lost. There is one manifest per package. >> >> It possible to use SmallLint with Manifest using the Critics Browser (menuWorld > Tool > CriticBrowser). With the Critics browser you can inspect violations of rules and mark them as false positive or true positive (ToDo) and see previous warnings flagged as false positives or toDo. >> In addition all the logic of the browser has been developed so that the manifest can be saved within the package without adding dependencies. >> We will continue to improve the Browser. In addition we will run SmallLint rules to all the Pharo packages and the rules checking will be part of the package validation. We want the community to use rule checking for real so that we all improve. >> >> Simon and Stef >> >> Gofer >> new >> url: 'http://www.squeaksource.com/PharoTaskForces'; >> package: 'ConfigurationOfManifest'; >> load. >> ((Smalltalk at: #ConfigurationOfManifest) project version: #stable) load > > -- > www.tudorgirba.com > > "Not knowing how to do something is not an argument for how it cannot be done." > >

April 7, 2012