Re: [Pharo-users] Probably a bug in Garage SQLite

[Herby Vojčík]

Stephane Ducasse wrote:

ah yes.
probably a missing rename during the migration to the new ffi.

Stef


Unfortunately there's more:

PharoDatabaseAccessor(DatabaseAccessor)>>handleError:for:
[ :ex | self handleError: ex for: command ] in [ | result |
self checkPermissionFor: command.
result := [ (self useBinding and: [ command useBinding ])
ifTrue: [ command executeBoundIn: self ]
ifFalse: [ command executeUnboundIn: self ] ]
on: Dialect error
do: [ :ex | self handleError: ex for: command ].
aBoolean
ifTrue: [ result ]
	ifFalse: [ result upToEnd ] ] in 
PharoDatabaseAccessor(DatabaseAccessor)>>executeCommand:returnCursor:

BlockClosure>>cull:
Context>>evaluateSignal:
Context>>handleSignal:
MessageNotUnderstood(Exception)>>signal
ExternalData(Object)>>doesNotUnderstand: #pointerAt:
FFIExternalArray class>>fromPointer:type:size:
GASqlite3FFI>>blobFrom:at:
GASqlite3Statement>>byteArrayAt:
GASqlite3Statement>>valueOfColumn:
GASqlite3ResultSet>>next
GASqlite3ResultSet>>rows
GAGlorpDriver>>basicExecuteSQLString:
PharoDatabaseAccessor>>basicExecuteSQLString:
PharoDatabaseAccessor>>executeCommandUnbound:
[..snip..]

Now ExternalData does not understand #pointerAt: (only ByteArray and 
FFIExternalStructureReferenceHandle do, don't know how to fix this 
quickly... :-( )


Herby



On Sun, Aug 13, 2017 at 9:04 PM, Herby Vojčík  wrote:

Stephane Ducasse wrote:

Do you have the same bug in 5.0?
Because I do not know if garage was really tested on 60.


Don't know (don't have it), but last commit in Garage-SQLite
GuillermoPolito.26 from 2016. The mentioned #nbBindingOf: is sent at no
place at all in the image (except supersend in the lone method itself), so
it definitely looks like it need to rename to ffiBindingOf: for 60.

Herby



Stef

On Sun, Aug 13, 2017 at 8:41 PM, Herby Vojčík   wrote:

Stephane Ducasse wrote:

Hi Herby

On which version of Pharo are you trying? Because lot of changes
happened on Pharo 60 FFI.

Stef

On Sun, Aug 13, 2017 at 6:11 PM, Herby Vojčíkwrote:

Hello!

This testing code:

| databaseFile login accessor sqlString |
   databaseFile := Smalltalk imageDirectory asFileReference /
'play.sqlite'.
   login := Login new
   database: SQLite3Platform new;
   host: '';
   port: '';
   username: '';
   password: '';
   databaseName: databaseFile fullPath asZnUrl
asString;
   yourself.
   accessor := DatabaseAccessor forLogin: login.
   accessor login.
   sqlString := 'SELECT * FROM AGENT'.
   (accessor basicExecuteSQLString: sqlString) contents inspect.

fails (Pharo 6.1, GarageGlorp #stable loaded a week ago as a project


As I wrote here, Pharo 6.1.



dependency) with:

Error: Unable to resolve external type: sqlite3

FFICallout(Object)>>error:
FFICallout>>resolveType:
FFICallout>>typeName:pointerArity:
FFICallout>>argName:indirectIndex:type:ptrArity:
FFIFunctionParser>>parseArgument
FFIFunctionParser>>parseArguments
FFIFunctionParser>>parseNamedFunction:
FFICalloutMethodBuilder>>parseSignature:
FFICalloutMethodBuilder>>generate
FFICalloutMethodBuilder>>build:
FFICalloutAPI>>function:module:
GASqlite3FFI(Object)>>ffiCall:module:
GASqlite3FFI>>apiErrorMessage:
GASqlite3FFI>>signal:with:on:
GASqlite3FFI>>checkForOk:on:
GASqlite3FFI>>prepare:on:with:
GASqlite3Statement>>prepare
GASqlite3Driver>>prepare:
GASqlite3ResultSet>>prepareStatement:
GASqlite3ResultSet>>execute:withCollection:
GASqlite3ResultSet>>execute:with:on:
GASqlite3Driver>>execute:with:
GASqlite3Driver>>execute:
GAGlorpDriver>>basicExecuteSQLString:
PharoDatabaseAccessor>>basicExecuteSQLString:
UndefinedObject>>DoIt
OpalCompiler>>evaluate
[..snip..]

Problem seems to be that in FFICallout>>resolveType:, the line

binding := resolver ffiBindingOf: name asSymbol.

actually produces nil, resolver being GASqlite3FFI class. If looking at
the
class side of GaSqlite3FFI, there is no ffiBindingOf: at all; there is

nbBindingOf: aTypeName
   ^ TypeMap at: aTypeName ifAbsent: [ super nbBindingOf:
aTypeName
]

though. If I copy near-mindlessly and add:

ffiBindingOf: aTypeName
   ^ TypeMap at: aTypeName ifAbsent: [ super ffiBindingOf:
aTypeName ]

then the code above fails correctly with: 'no such table: AGENT'.

Am I missing some nb<->ffi bridge? Or is there a bug in Garage SQLite
driver?

Herby

Re: [Pharo-users] Probably a bug in Garage SQLite

[Stephane Ducasse]

ah yes.
probably a missing rename during the migration to the new ffi.

Stef

On Sun, Aug 13, 2017 at 9:04 PM, Herby Vojčík  wrote:
> Stephane Ducasse wrote:
>>
>> Do you have the same bug in 5.0?
>> Because I do not know if garage was really tested on 60.
>
>
> Don't know (don't have it), but last commit in Garage-SQLite
> GuillermoPolito.26 from 2016. The mentioned #nbBindingOf: is sent at no
> place at all in the image (except supersend in the lone method itself), so
> it definitely looks like it need to rename to ffiBindingOf: for 60.
>
> Herby
>
>
>>
>> Stef
>>
>> On Sun, Aug 13, 2017 at 8:41 PM, Herby Vojčík  wrote:
>>>
>>> Stephane Ducasse wrote:

 Hi Herby

 On which version of Pharo are you trying? Because lot of changes
 happened on Pharo 60 FFI.

 Stef

 On Sun, Aug 13, 2017 at 6:11 PM, Herby Vojčík   wrote:
>
> Hello!
>
> This testing code:
>
> | databaseFile login accessor sqlString |
>   databaseFile := Smalltalk imageDirectory asFileReference /
> 'play.sqlite'.
>   login := Login new
>   database: SQLite3Platform new;
>   host: '';
>   port: '';
>   username: '';
>   password: '';
>   databaseName: databaseFile fullPath asZnUrl
> asString;
>   yourself.
>   accessor := DatabaseAccessor forLogin: login.
>   accessor login.
>   sqlString := 'SELECT * FROM AGENT'.
>   (accessor basicExecuteSQLString: sqlString) contents inspect.
>
> fails (Pharo 6.1, GarageGlorp #stable loaded a week ago as a project
>>>
>>>
>>> As I wrote here, Pharo 6.1.
>>>
>>>
> dependency) with:
>
> Error: Unable to resolve external type: sqlite3
>
> FFICallout(Object)>>error:
> FFICallout>>resolveType:
> FFICallout>>typeName:pointerArity:
> FFICallout>>argName:indirectIndex:type:ptrArity:
> FFIFunctionParser>>parseArgument
> FFIFunctionParser>>parseArguments
> FFIFunctionParser>>parseNamedFunction:
> FFICalloutMethodBuilder>>parseSignature:
> FFICalloutMethodBuilder>>generate
> FFICalloutMethodBuilder>>build:
> FFICalloutAPI>>function:module:
> GASqlite3FFI(Object)>>ffiCall:module:
> GASqlite3FFI>>apiErrorMessage:
> GASqlite3FFI>>signal:with:on:
> GASqlite3FFI>>checkForOk:on:
> GASqlite3FFI>>prepare:on:with:
> GASqlite3Statement>>prepare
> GASqlite3Driver>>prepare:
> GASqlite3ResultSet>>prepareStatement:
> GASqlite3ResultSet>>execute:withCollection:
> GASqlite3ResultSet>>execute:with:on:
> GASqlite3Driver>>execute:with:
> GASqlite3Driver>>execute:
> GAGlorpDriver>>basicExecuteSQLString:
> PharoDatabaseAccessor>>basicExecuteSQLString:
> UndefinedObject>>DoIt
> OpalCompiler>>evaluate
> [..snip..]
>
> Problem seems to be that in FFICallout>>   resolveType:, the line
>
> binding := resolver ffiBindingOf: name asSymbol.
>
> actually produces nil, resolver being GASqlite3FFI class. If looking at
> the
> class side of GaSqlite3FFI, there is no ffiBindingOf: at all; there is
>
> nbBindingOf: aTypeName
>   ^ TypeMap at: aTypeName ifAbsent: [ super nbBindingOf:
> aTypeName
> ]
>
> though. If I copy near-mindlessly and add:
>
> ffiBindingOf: aTypeName
>   ^ TypeMap at: aTypeName ifAbsent: [ super ffiBindingOf:
> aTypeName ]
>
> then the code above fails correctly with: 'no such table: AGENT'.
>
> Am I missing some nb<->ffi bridge? Or is there a bug in Garage SQLite
> driver?
>
> Herby
>>>
>>>
>>
>
>

Re: [Pharo-users] pharo config problem

[Johannes Brauer]

Hi Stef,

the connection from a Monticello Browser in a local image with same username 
and password works fine.

Johannes
> Am 13.08.2017 um 20:34 schrieb Stephane Ducasse :
> 
> Hi johannes
> 
> I do not know how to help you but this is strange.
> We managed our synectique private code on STHub and it works.
> Now STHub is getting stranger and stranger. So may be your passwrd got desync.
> Esteban? if you read this mail. Can you check when you are back from vacation?
> 
> Stef
> 
> On Sun, Aug 13, 2017 at 7:20 PM, jb  wrote:
>> Hi,
>> 
>> I have a problem with connection to a private smalltalkhub rep from the
>> command line with pharo config.
>> I think I set the --username and --password options correctly, but I always
>> get:
>> ZnHttpUnsuccessful: 403 Forbidded
>> 
>> If I make the rep public then there is no access problem.
>> 
>> Any hints what is going wrong?
>> 
>> Johannes
>> 
>> 
>> 
>> --
>> View this message in context: 
>> http://forum.world.st/pharo-config-problem-tp4960715.html
>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>> 
> 

Re: [Pharo-users] including Pillar in Pharo image by default

[Stephane Ducasse]

Hi tim

I personally do not care much about the syntax but I care about what I
can do with it
(ref, cite, ... )
I cannot write books in markdown because reference to figures!!
were missing.

And of course a parser because markdown is not really nice to parse
and I will not write a parser because I have something else to do. I
want to make pillar smaller, simpler, nicer.

Now if someone come up with a parser that parse for REAL a markdown
that can be extended with decent behavior (figure reference, section
reference, cite) and can be extended because there are many things
that can be nice to have (for example I want to be able to write the
example below) and emit a PillarModel (AST) we can talk to have
another syntax for Pillar but not before.

[[[test
2+3
>>> 5
]]]

and being able to verify that the doc is in sync.


Stef



On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon  wrote:
> Of course, I/we recognise and appreciate all the work that's gone into docs 
> in pillar - but I think it should be reasonably straightforward to write a 
> converter as it is pretty closely related from what I have seen.
>
> So I don't make the suggestion flippantly, and would want to help write a 
> converter and get us to a common ground where we can differentiate on the 
> aspects where we can excel.
>
> Tim
>
> Sent from my iPhone
>
>> On 11 Aug 2017, at 23:21, Peter Uhnak  wrote:
>>
>> A long time issue with Markdown was that there was no standardization (and 
>> when I used Pillar's MD export ~2 years ago it didn't work well).
>>
>> However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the 
>> de-facto standard, so it would make sense to support it bidirectionally with 
>> Pillar.
>>
>>> The readme.md that Peter is talking about is gfm markdown
>>
>> Well, technically it is just a CommonMark, as I am not using any github 
>> extensions.
>> (Github uses CommonMarks and adds just couple small extensions.)
>>
>> Peter
>>
>
>

Re: [Pharo-users] Probably a bug in Garage SQLite

[Herby Vojčík]

Stephane Ducasse wrote:

Do you have the same bug in 5.0?
Because I do not know if garage was really tested on 60.


Don't know (don't have it), but last commit in Garage-SQLite 
GuillermoPolito.26 from 2016. The mentioned #nbBindingOf: is sent at no 
place at all in the image (except supersend in the lone method itself), 
so it definitely looks like it need to rename to ffiBindingOf: for 60.


Herby



Stef

On Sun, Aug 13, 2017 at 8:41 PM, Herby Vojčík  wrote:

Stephane Ducasse wrote:

Hi Herby

On which version of Pharo are you trying? Because lot of changes
happened on Pharo 60 FFI.

Stef

On Sun, Aug 13, 2017 at 6:11 PM, Herby Vojčík   wrote:

Hello!

This testing code:

| databaseFile login accessor sqlString |
  databaseFile := Smalltalk imageDirectory asFileReference /
'play.sqlite'.
  login := Login new
  database: SQLite3Platform new;
  host: '';
  port: '';
  username: '';
  password: '';
  databaseName: databaseFile fullPath asZnUrl
asString;
  yourself.
  accessor := DatabaseAccessor forLogin: login.
  accessor login.
  sqlString := 'SELECT * FROM AGENT'.
  (accessor basicExecuteSQLString: sqlString) contents inspect.

fails (Pharo 6.1, GarageGlorp #stable loaded a week ago as a project


As I wrote here, Pharo 6.1.



dependency) with:

Error: Unable to resolve external type: sqlite3

FFICallout(Object)>>error:
FFICallout>>resolveType:
FFICallout>>typeName:pointerArity:
FFICallout>>argName:indirectIndex:type:ptrArity:
FFIFunctionParser>>parseArgument
FFIFunctionParser>>parseArguments
FFIFunctionParser>>parseNamedFunction:
FFICalloutMethodBuilder>>parseSignature:
FFICalloutMethodBuilder>>generate
FFICalloutMethodBuilder>>build:
FFICalloutAPI>>function:module:
GASqlite3FFI(Object)>>ffiCall:module:
GASqlite3FFI>>apiErrorMessage:
GASqlite3FFI>>signal:with:on:
GASqlite3FFI>>checkForOk:on:
GASqlite3FFI>>prepare:on:with:
GASqlite3Statement>>prepare
GASqlite3Driver>>prepare:
GASqlite3ResultSet>>prepareStatement:
GASqlite3ResultSet>>execute:withCollection:
GASqlite3ResultSet>>execute:with:on:
GASqlite3Driver>>execute:with:
GASqlite3Driver>>execute:
GAGlorpDriver>>basicExecuteSQLString:
PharoDatabaseAccessor>>basicExecuteSQLString:
UndefinedObject>>DoIt
OpalCompiler>>evaluate
[..snip..]

Problem seems to be that in FFICallout>>   resolveType:, the line

binding := resolver ffiBindingOf: name asSymbol.

actually produces nil, resolver being GASqlite3FFI class. If looking at
the
class side of GaSqlite3FFI, there is no ffiBindingOf: at all; there is

nbBindingOf: aTypeName
  ^ TypeMap at: aTypeName ifAbsent: [ super nbBindingOf: aTypeName
]

though. If I copy near-mindlessly and add:

ffiBindingOf: aTypeName
  ^ TypeMap at: aTypeName ifAbsent: [ super ffiBindingOf:
aTypeName ]

then the code above fails correctly with: 'no such table: AGENT'.

Am I missing some nb<->ffi bridge? Or is there a bug in Garage SQLite
driver?

Herby

Re: [Pharo-users] Probably a bug in Garage SQLite

[Stephane Ducasse]

Do you have the same bug in 5.0?
Because I do not know if garage was really tested on 60.

Stef

On Sun, Aug 13, 2017 at 8:41 PM, Herby Vojčík  wrote:
> Stephane Ducasse wrote:
>>
>> Hi Herby
>>
>> On which version of Pharo are you trying? Because lot of changes
>> happened on Pharo 60 FFI.
>>
>> Stef
>>
>> On Sun, Aug 13, 2017 at 6:11 PM, Herby Vojčík  wrote:
>>>
>>> Hello!
>>>
>>> This testing code:
>>>
>>> | databaseFile login accessor sqlString |
>>>  databaseFile := Smalltalk imageDirectory asFileReference /
>>> 'play.sqlite'.
>>>  login := Login new
>>>  database: SQLite3Platform new;
>>>  host: '';
>>>  port: '';
>>>  username: '';
>>>  password: '';
>>>  databaseName: databaseFile fullPath asZnUrl
>>> asString;
>>>  yourself.
>>>  accessor := DatabaseAccessor forLogin: login.
>>>  accessor login.
>>>  sqlString := 'SELECT * FROM AGENT'.
>>>  (accessor basicExecuteSQLString: sqlString) contents inspect.
>>>
>>> fails (Pharo 6.1, GarageGlorp #stable loaded a week ago as a project
>
>
> As I wrote here, Pharo 6.1.
>
>
>>> dependency) with:
>>>
>>> Error: Unable to resolve external type: sqlite3
>>>
>>> FFICallout(Object)>>error:
>>> FFICallout>>resolveType:
>>> FFICallout>>typeName:pointerArity:
>>> FFICallout>>argName:indirectIndex:type:ptrArity:
>>> FFIFunctionParser>>parseArgument
>>> FFIFunctionParser>>parseArguments
>>> FFIFunctionParser>>parseNamedFunction:
>>> FFICalloutMethodBuilder>>parseSignature:
>>> FFICalloutMethodBuilder>>generate
>>> FFICalloutMethodBuilder>>build:
>>> FFICalloutAPI>>function:module:
>>> GASqlite3FFI(Object)>>ffiCall:module:
>>> GASqlite3FFI>>apiErrorMessage:
>>> GASqlite3FFI>>signal:with:on:
>>> GASqlite3FFI>>checkForOk:on:
>>> GASqlite3FFI>>prepare:on:with:
>>> GASqlite3Statement>>prepare
>>> GASqlite3Driver>>prepare:
>>> GASqlite3ResultSet>>prepareStatement:
>>> GASqlite3ResultSet>>execute:withCollection:
>>> GASqlite3ResultSet>>execute:with:on:
>>> GASqlite3Driver>>execute:with:
>>> GASqlite3Driver>>execute:
>>> GAGlorpDriver>>basicExecuteSQLString:
>>> PharoDatabaseAccessor>>basicExecuteSQLString:
>>> UndefinedObject>>DoIt
>>> OpalCompiler>>evaluate
>>> [..snip..]
>>>
>>> Problem seems to be that in FFICallout>>  resolveType:, the line
>>>
>>> binding := resolver ffiBindingOf: name asSymbol.
>>>
>>> actually produces nil, resolver being GASqlite3FFI class. If looking at
>>> the
>>> class side of GaSqlite3FFI, there is no ffiBindingOf: at all; there is
>>>
>>> nbBindingOf: aTypeName
>>>  ^ TypeMap at: aTypeName ifAbsent: [ super nbBindingOf: aTypeName
>>> ]
>>>
>>> though. If I copy near-mindlessly and add:
>>>
>>> ffiBindingOf: aTypeName
>>>  ^ TypeMap at: aTypeName ifAbsent: [ super ffiBindingOf:
>>> aTypeName ]
>>>
>>> then the code above fails correctly with: 'no such table: AGENT'.
>>>
>>> Am I missing some nb<->ffi bridge? Or is there a bug in Garage SQLite
>>> driver?
>>>
>>> Herby
>
>

Re: [Pharo-users] Probably a bug in Garage SQLite

[Herby Vojčík]

Stephane Ducasse wrote:

Hi Herby

On which version of Pharo are you trying? Because lot of changes
happened on Pharo 60 FFI.

Stef

On Sun, Aug 13, 2017 at 6:11 PM, Herby Vojčík  wrote:

Hello!

This testing code:

| databaseFile login accessor sqlString |
 databaseFile := Smalltalk imageDirectory asFileReference /
'play.sqlite'.
 login := Login new
 database: SQLite3Platform new;
 host: '';
 port: '';
 username: '';
 password: '';
 databaseName: databaseFile fullPath asZnUrl
asString;
 yourself.
 accessor := DatabaseAccessor forLogin: login.
 accessor login.
 sqlString := 'SELECT * FROM AGENT'.
 (accessor basicExecuteSQLString: sqlString) contents inspect.

fails (Pharo 6.1, GarageGlorp #stable loaded a week ago as a project


As I wrote here, Pharo 6.1.


dependency) with:

Error: Unable to resolve external type: sqlite3

FFICallout(Object)>>error:
FFICallout>>resolveType:
FFICallout>>typeName:pointerArity:
FFICallout>>argName:indirectIndex:type:ptrArity:
FFIFunctionParser>>parseArgument
FFIFunctionParser>>parseArguments
FFIFunctionParser>>parseNamedFunction:
FFICalloutMethodBuilder>>parseSignature:
FFICalloutMethodBuilder>>generate
FFICalloutMethodBuilder>>build:
FFICalloutAPI>>function:module:
GASqlite3FFI(Object)>>ffiCall:module:
GASqlite3FFI>>apiErrorMessage:
GASqlite3FFI>>signal:with:on:
GASqlite3FFI>>checkForOk:on:
GASqlite3FFI>>prepare:on:with:
GASqlite3Statement>>prepare
GASqlite3Driver>>prepare:
GASqlite3ResultSet>>prepareStatement:
GASqlite3ResultSet>>execute:withCollection:
GASqlite3ResultSet>>execute:with:on:
GASqlite3Driver>>execute:with:
GASqlite3Driver>>execute:
GAGlorpDriver>>basicExecuteSQLString:
PharoDatabaseAccessor>>basicExecuteSQLString:
UndefinedObject>>DoIt
OpalCompiler>>evaluate
[..snip..]

Problem seems to be that in FFICallout>>  resolveType:, the line

binding := resolver ffiBindingOf: name asSymbol.

actually produces nil, resolver being GASqlite3FFI class. If looking at the
class side of GaSqlite3FFI, there is no ffiBindingOf: at all; there is

nbBindingOf: aTypeName
 ^ TypeMap at: aTypeName ifAbsent: [ super nbBindingOf: aTypeName ]

though. If I copy near-mindlessly and add:

ffiBindingOf: aTypeName
 ^ TypeMap at: aTypeName ifAbsent: [ super ffiBindingOf: aTypeName ]

then the code above fails correctly with: 'no such table: AGENT'.

Am I missing some nb<->ffi bridge? Or is there a bug in Garage SQLite
driver?

Herby

Re: [Pharo-users] (no subject)

[Stephane Ducasse]

Christophe did a pass because he faced the same problem and he
improved the situation.
Now he left on vacation (and was stopped because of a huge jenkins
crash because he left) and I do not know
the status. (because we are also annoyed and sorry than you by the situation).

Stef




On Sun, Aug 13, 2017 at 10:31 AM, Vityou .  wrote:
> I recently discovered the pharo launcher.  However, it only gives me options
> to use outdated images, and I'm not sure about the vm.  Is there any way to
> change this?

Re: [Pharo-users] Probably a bug in Garage SQLite

[Stephane Ducasse]

Hi Herby

On which version of Pharo are you trying? Because lot of changes
happened on Pharo 60 FFI.

Stef

On Sun, Aug 13, 2017 at 6:11 PM, Herby Vojčík  wrote:
> Hello!
>
> This testing code:
>
> | databaseFile login accessor sqlString |
> databaseFile := Smalltalk imageDirectory asFileReference /
> 'play.sqlite'.
> login := Login new
> database: SQLite3Platform new;
> host: '';
> port: '';
> username: '';
> password: '';
> databaseName: databaseFile fullPath asZnUrl
> asString;
> yourself.
> accessor := DatabaseAccessor forLogin: login.
> accessor login.
> sqlString := 'SELECT * FROM AGENT'.
> (accessor basicExecuteSQLString: sqlString) contents inspect.
>
> fails (Pharo 6.1, GarageGlorp #stable loaded a week ago as a project
> dependency) with:
>
> Error: Unable to resolve external type: sqlite3
>
> FFICallout(Object)>>error:
> FFICallout>>resolveType:
> FFICallout>>typeName:pointerArity:
> FFICallout>>argName:indirectIndex:type:ptrArity:
> FFIFunctionParser>>parseArgument
> FFIFunctionParser>>parseArguments
> FFIFunctionParser>>parseNamedFunction:
> FFICalloutMethodBuilder>>parseSignature:
> FFICalloutMethodBuilder>>generate
> FFICalloutMethodBuilder>>build:
> FFICalloutAPI>>function:module:
> GASqlite3FFI(Object)>>ffiCall:module:
> GASqlite3FFI>>apiErrorMessage:
> GASqlite3FFI>>signal:with:on:
> GASqlite3FFI>>checkForOk:on:
> GASqlite3FFI>>prepare:on:with:
> GASqlite3Statement>>prepare
> GASqlite3Driver>>prepare:
> GASqlite3ResultSet>>prepareStatement:
> GASqlite3ResultSet>>execute:withCollection:
> GASqlite3ResultSet>>execute:with:on:
> GASqlite3Driver>>execute:with:
> GASqlite3Driver>>execute:
> GAGlorpDriver>>basicExecuteSQLString:
> PharoDatabaseAccessor>>basicExecuteSQLString:
> UndefinedObject>>DoIt
> OpalCompiler>>evaluate
> [..snip..]
>
> Problem seems to be that in FFICallout >> resolveType:, the line
>
> binding := resolver ffiBindingOf: name asSymbol.
>
> actually produces nil, resolver being GASqlite3FFI class. If looking at the
> class side of GaSqlite3FFI, there is no ffiBindingOf: at all; there is
>
> nbBindingOf: aTypeName
> ^ TypeMap at: aTypeName ifAbsent: [ super nbBindingOf: aTypeName ]
>
> though. If I copy near-mindlessly and add:
>
> ffiBindingOf: aTypeName
> ^ TypeMap at: aTypeName ifAbsent: [ super ffiBindingOf: aTypeName ]
>
> then the code above fails correctly with: 'no such table: AGENT'.
>
> Am I missing some nb<->ffi bridge? Or is there a bug in Garage SQLite
> driver?
>
> Herby
>

Re: [Pharo-users] pharo config problem

[Stephane Ducasse]

Hi johannes

I do not know how to help you but this is strange.
We managed our synectique private code on STHub and it works.
Now STHub is getting stranger and stranger. So may be your passwrd got desync.
Esteban? if you read this mail. Can you check when you are back from vacation?

Stef

On Sun, Aug 13, 2017 at 7:20 PM, jb  wrote:
> Hi,
>
> I have a problem with connection to a private smalltalkhub rep from the
> command line with pharo config.
> I think I set the --username and --password options correctly, but I always
> get:
> ZnHttpUnsuccessful: 403 Forbidded
>
> If I make the rep public then there is no access problem.
>
> Any hints what is going wrong?
>
> Johannes
>
>
>
> --
> View this message in context: 
> http://forum.world.st/pharo-config-problem-tp4960715.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>

[Pharo-users] pharo config problem

[jb]

Hi,

I have a problem with connection to a private smalltalkhub rep from the
command line with pharo config.
I think I set the --username and --password options correctly, but I always
get:
ZnHttpUnsuccessful: 403 Forbidded

If I make the rep public then there is no access problem.

Any hints what is going wrong?

Johannes



--
View this message in context: 
http://forum.world.st/pharo-config-problem-tp4960715.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

[Pharo-users] Probably a bug in Garage SQLite

[Herby Vojčík]

Hello!

This testing code:

| databaseFile login accessor sqlString |
databaseFile := Smalltalk imageDirectory asFileReference / 
'play.sqlite'.
login := Login new
database: SQLite3Platform new;
host: '';
port: '';
username: '';
password: '';
databaseName: databaseFile fullPath asZnUrl asString;
yourself.
accessor := DatabaseAccessor forLogin: login.
accessor login.
sqlString := 'SELECT * FROM AGENT'.
(accessor basicExecuteSQLString: sqlString) contents inspect.

fails (Pharo 6.1, GarageGlorp #stable loaded a week ago as a project 
dependency) with:


Error: Unable to resolve external type: sqlite3

FFICallout(Object)>>error:
FFICallout>>resolveType:
FFICallout>>typeName:pointerArity:
FFICallout>>argName:indirectIndex:type:ptrArity:
FFIFunctionParser>>parseArgument
FFIFunctionParser>>parseArguments
FFIFunctionParser>>parseNamedFunction:
FFICalloutMethodBuilder>>parseSignature:
FFICalloutMethodBuilder>>generate
FFICalloutMethodBuilder>>build:
FFICalloutAPI>>function:module:
GASqlite3FFI(Object)>>ffiCall:module:
GASqlite3FFI>>apiErrorMessage:
GASqlite3FFI>>signal:with:on:
GASqlite3FFI>>checkForOk:on:
GASqlite3FFI>>prepare:on:with:
GASqlite3Statement>>prepare
GASqlite3Driver>>prepare:
GASqlite3ResultSet>>prepareStatement:
GASqlite3ResultSet>>execute:withCollection:
GASqlite3ResultSet>>execute:with:on:
GASqlite3Driver>>execute:with:
GASqlite3Driver>>execute:
GAGlorpDriver>>basicExecuteSQLString:
PharoDatabaseAccessor>>basicExecuteSQLString:
UndefinedObject>>DoIt
OpalCompiler>>evaluate
[..snip..]

Problem seems to be that in FFICallout >> resolveType:, the line

binding := resolver ffiBindingOf: name asSymbol.

actually produces nil, resolver being GASqlite3FFI class. If looking at 
the class side of GaSqlite3FFI, there is no ffiBindingOf: at all; there is


nbBindingOf: aTypeName
^ TypeMap at: aTypeName ifAbsent: [ super nbBindingOf: aTypeName ]

though. If I copy near-mindlessly and add:

ffiBindingOf: aTypeName
^ TypeMap at: aTypeName ifAbsent: [ super ffiBindingOf: aTypeName ]

then the code above fails correctly with: 'no such table: AGENT'.

Am I missing some nb<->ffi bridge? Or is there a bug in Garage SQLite 
driver?


Herby

Re: [Pharo-users] (no subject)

[Guillermo Polito]

On Sun, Aug 13, 2017 at 10:31 AM, Vityou .  wrote:

> I recently discovered the pharo launcher.  However, it only gives me
> options to use outdated images, and I'm not sure about the vm.  Is there
> any way to change this?
>

Usually it will download the right vm for your image so you don't have to
care.



-- 



Guille Polito


Research Engineer

French National Center for Scientific Research - *http://www.cnrs.fr*




*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-users] including Pillar in Pharo image by default

[Norbert Hartl]

Hi,

> Am 11.08.2017 um 21:10 schrieb Esteban Lorenzano :
> 
> hi, 
> 
>> On 11 Aug 2017, at 18:57, Cyril Ferlicot D. > > wrote:
>> 
>> Another step would be to get a minimal parser not relying on
>> PetitParser. 
> 
> Let’s think differently: why not to include a tiny PetitParser? 
> Then we can think on:
> 
> - pillar sintax (better than just a restricted version)
> - simplify other “small parsers” that are already on the image.
> - we provide a tool to o cool stuff (instead relying as always in regexp, 
> etc.) 
> 

+1 I like that. I always feel bad if I use regex in pharo because I think I can 
do better. But then installing petit parser just to do some parsing sounds 
heavy weight. And parsing is such central functionality that it would be good 
to have a small parser near the core. For pillar I would like to see that class 
comments are a layer on top of the image core. It is metadata that can be 
optional and pillar could be a dependency to that layer. This would make it 
possible to strip out on deployment, too. Because I don't need class comments 
on my server :)

Norbert

[Pharo-users] (no subject)

[Vityou .]

I recently discovered the pharo launcher.  However, it only gives me
options to use outdated images, and I'm not sure about the vm.  Is there
any way to change this?