Re: [Pharo-users] GlorpSQLite not finding sqlite library on Mac

[Pierce Ng]

On Sun, Dec 16, 2018 at 10:25:11AM -0800, Todd Blanchard via Pharo-users wrote:
> Metacello new 
>   repository: 'github://pharo-rdbms/glorp-sqlite3';
>   baseline: 'GlorpSQLite';
>   load.

Hi Todd,

Pharo 6 or 7? 32- or 64-bit?

> This seems to be the only way to get SQLite support?  There is no
> standalone UFFI library?  Not that I have a problem with it, I know
> and like GLORP.

GlorpSQLite is built on the standalone SQLite UFFI library. 

> Then I ran the basic UDBCSQLite tests and they all fail with 'External
> module not found'.  I presume this means that the sqlite library was
> not found but the best I can find is a method #library that returns
> #sqlite 
> Reading the well written
> https://files.pharo.org/books-pdfs/booklet-uFFI/UFFIDRAFT.pdf I gather
> that I should subclass FFILibrary to make a SQLiteLibrary and have
> UDBCSQLite class that implements  #macModuleName to return
> '/usr/local/Cellar/libspatialite/4.3.0a_6/libspatialite.dylib'?

The library was written before that convention was established.
Currently it is UDBCSQLite3Library (subclassing Object) and its #library
says this:

  library
Smalltalk os isMacOS ifTrue: [ ^ #sqlite3 ].
^ 'sqlite3'

This worked before as I had used it with Pharo 5 when my Mac was on El
Capitan and Sierra. The Mac is now on High Sierra. 

Testing... Ok, the system-supplied library is named libsqlite3.0.dylib.
After some experimentation, copying/renaming said library works:

  % cp -p /usr/lib/libsqlite3.0.dylib % 
~/Pharo.app/Contents/MacOS/Plugins/libsqlite3.dylib

Now 64-bit Pharo 60543 finds the dylib, the SQLite tests run and pass.
I also tested keeping the '3.0' in the dylib file name, modifying the
#library method accordingly, and evaluating 'UDBCSQLite3Library reset'
to clear the singleton class variable.

I've not run into this situation before because I've always used my own
custom SQLite shared library that includes JSON, FTS etc extensions.

For good measure I also ran the Glorp tests and got 891 run, 890 passes,
1 error. The error is due to my changing SQLite's boolean handling, see 

  https://www.samadhiweb.com/blog/2018.05.20.sqlite.boolean.html

The test error has been fixed for Pharo 7. Not yet back-ported for Pharo
6. 

To load GlorpSQLite for Pharo 7, use the Catalog Browser, or,
equivalently, load from my repo:

  Metacello new 
repository: 'github://PierceNg/glorp-sqlite3:pharo7';
baseline: 'GlorpSQLite';
load.

> spatialite

Cool! Please let me know how this goes. 

Back in Pharo 4's Native Boost days, NBSQLite as it was called then
supported both SQLite and SQLcipher. I had experimented with loading
libsqlcipher3 from UDBCSQLcipher3Library, which subclasses
UDBCSQLite3Library, and IIRC also via some class variable in
UDBCSQLite3Library determining which shared library to load. Torsten
Bergmann kindly ported NBSQLite to UFFI. The SQLcipher part is still on
my to-do list, and I am also interested to have (Glorp|UDBC)SQLite load
Spatialite (and maybe even libspatialitecipher) cleanly.

Pierce

[Pharo-users] MongoCursor>>execute raising 'Unexpected responseTo in response'

[Sebastian Sastre]

Hi All, Holger...

I’ve seen this today:
http://forum.world.st/MongoCursor-gt-gt-execute-and-MongoTalk-changes-td4889293.html
 



After talking with some people in the Pharo chat group at Discord about this 
erratic error I’m having with MongoTalk’s MongoCursor .



Once it happens, the stream stays open and Mongo says isValid true but no other 
operations can be executed.

I’ve loaded MongoTalk with:

Metacello new 
githubUser: 'pharo-nosql' project: 'voyage' commitish:'1.?' path: 'mc';
baseline: 'Voyage';
load: 'mongo’.

in a Pharo 6.1 image.

Did this Unexpected responseTo happened again to you?

nextRequestID has the code you mention in the issue:

nextRequestID
^requestID := requestID + 1 bitAnd: 16r3FFF

Do you have any further hint on why the issue? Thanks!


Sebastian

Re: [Pharo-users] voygae on P7 install problens on Windows

[Ben Coman]

On Mon, 17 Dec 2018 at 03:25, Roelof Wobben  wrote:

> Hello
>
> Are there more people who cannot install voyage on Windows
> I see a message that the name is too long
>

Could you clarify this last statement...


> where pharo works on the root
>

Did you mean you are already running pharo from somewhere like "C:\pharo" ?
...which was the first thing I would suggest trying?

cheers -ben

[Pharo-users] voygae on P7 install problens on Windows

[Roelof Wobben]

  
  
Hello

Are there more people who cannot install voyage on Windows

  

  I see a message that the name is
too long

  

where pharo works on the root

Regards, 

Roelof

  

[Pharo-users] GlorpSQLite not finding sqlite library on Mac

[Todd Blanchard via Pharo-users]

--- Begin Message ---
I loaded up Glorp SQLite using

Metacello new 
repository: 'github://pharo-rdbms/glorp-sqlite3';
baseline: 'GlorpSQLite';
load.


This seems to be the only way to get SQLite support?  There is no standalone 
UFFI library?  Not that I have a problem with it, I know and like GLORP.

Then I ran the basic UDBCSQLite tests and they all fail with 'External module 
not found'.

I'm on MacOS Mojave.

I presume this means that the sqlite library was not found but the best I can 
find is a method #library that returns #sqlite

I want to use a homebrew installed version sqlite (technically, I want to use 
spatialite which is an extended version with GIS extensions).  

Reading the well written 
https://files.pharo.org/books-pdfs/booklet-uFFI/UFFIDRAFT.pdf I gather that I 
should subclass FFILibrary to make a SQLiteLibrary and have UDBCSQLite class 
that implements  
#macModuleName to return 
'/usr/local/Cellar/libspatialite/4.3.0a_6/libspatialite.dylib'?



--- End Message ---

Re: [Pharo-users] chooseExistingFileReference:extensions:path:preview returning wrong FileReference?

[Arturo Zambrano]

Thanks I have tested it, and it is working in the case I was using when I
reported the problem.



On Fri, Dec 14, 2018 at 10:48 AM Guillermo Polito 
wrote:

> Hi all,
>
> I've created issue
> https://pharo.fogbugz.com/f/cases/22772/chooseExistingFileReference-extensions-path-preview-returning-wrong-FileReference
>
> And proposed a single-line fix:
> https://github.com/pharo-project/pharo/pull/2075
>
> I've tested those scenarios and it was working but some more testing would
> not hurt :)
> Guille
>
> On Tue, Dec 11, 2018 at 11:15 PM Ben Coman  wrote:
>
>> https://pharo.fogbugz.com
>>
>> On Wed, 12 Dec 2018 at 01:54, Arturo Zambrano 
>> wrote:
>>
>>>  Should I report a bug? If so please send me the link to thw issue
>>> tracker
>>>
>>> On Tue, 11 Dec 2018, 13:05 Sven Van Caekenberghe,  wrote:
>>>
 I confirm that this does indeed seem to be a problem, weird.

 > On 11 Dec 2018, at 16:53, Arturo Zambrano 
 wrote:
 >
 > Hi All,
 >  I'm  replacing a deprecated call by this:
 > UIManager default
 chooseExistingFileReference:extensions:path:preview:.
 >
 > The returned fileRefence does not point the actual file selected by
 the user (if the file was chosen navigating to other directories than the
 default).
 > For example:
 >
 > UIManager default chooseExistingFileReference:'Title'
 extensions:#('pdf') path: './' preview: nil
 >
 > 
 >
 > Inspect the result:
 > 
 >
 >
 >
 > It seems to be a bug, or maybe there  is any other way to call the
 dialog.
 >
 > Any pointer is welcome.
 >
 > TIA
 >
 >
 >



>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> 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] some help to find the bug

[Ben Coman]

On Sun, 16 Dec 2018 at 19:57, Roelof Wobben  wrote:

> Op 16-12-2018 om 12:34 schreef Ben Coman:
>
>
>
> On Sun, 16 Dec 2018 at 02:37, Roelof Wobben  wrote:
>
>> Hello,
>>
>> I have this code :
>> https://gist.github.com/RoelofWobben/7c08680797d1d9f84436653a0e4edd3b
>> as  my solution to a AoC challenge.
>>
>>
>> But the last test `testIsNice`  is still  outputting the wrong output.
>> The right output is :   `ugknbfddgicrmopn ` and `aaa`
>>
>> Someone who can think with me where I make a thinking error so that the
>> right output is seen.
>>
>
> You seem to already have fixed that problem, so just some general
> feedback...
>
> Your #isNice is an instance method, so you are already inside
> a FindNiceStrings object.
> So you don't need...
> ```niceStringsObject := FindNiceStrings new.```
> Just use self.
>
> By convention, all #isX methods should return a Boolean
> Your ```isNice: aCollection``` method returns a collection. That would be
> better renamed #selectNice:
>
> The two #and: messages inside the #select: makes that a bit verbose.
> I'd refactor that condition out to its own method, i.e. ```isNice:
> aWord``` since that was freed up
> So you would have:
> ```
> FindNiceStrings  selectNice: aCollection
> ^ aCollection select: [ :word | self isNice: word ]
> ```
>
>
> > self assert: (FindNiceStrings new checkForbiddenParts: string) equals:
> true
>
> The "equals: true" part is redundant.
>
> cheers -ben
>
>
>
> Thanks,
>
> So the isNice function has all the code with the 2 times and.
>
> and what must i use when a test is false so instead of equals:  false
>


Evaluate this... ```#deny: senders inspect```

Re: [Pharo-users] some help to find the bug

[Roelof Wobben]

  
  
Op 16-12-2018 om 12:34 schreef Ben
  Coman:


  
  

  

  




  On Sun, 16 Dec 2018 at 02:37, Roelof
Wobben 
wrote:
  
  
 Hello, 
  
  I have this code : https://gist.github.com/RoelofWobben/7c08680797d1d9f84436653a0e4edd3b
  as  my solution to a AoC challenge.
  
  
  But the last test `testIsNice`  is still 
  outputting the wrong output.
  The right output is :   `ugknbfddgicrmopn `
and `aaa` 

Someone who can think with me where I make a
thinking error so that the right output is seen.
  
  
  
  
  You seem to already have fixed that problem, so
just some general feedback...
  
  
  Your #isNice is an instance method, so you are
already inside a FindNiceStrings object.
  So you don't need... 
  ```niceStringsObject := FindNiceStrings new.```
  
  Just use self.
  
  
  By convention, all #isX methods should return
a Boolean
  Your ```isNice: aCollection``` method returns a
collection. That would be better renamed
#selectNice:
  
  
  The two #and: messages inside the #select: makes
that a bit verbose.
  I'd refactor that condition out to its own
method, i.e. ```isNice: aWord``` since that was
freed up
  So you would have:
  ```    
  
FindNiceStrings  selectNice: aCollection
	^
  aCollection select: [ :word | self isNice: word ]
  
  ```
  
  
  
  
  > self assert: (FindNiceStrings new
checkForbiddenParts: string) equals: true
  
  
  The "equals: true" part is redundant.
  
  
  cheers -ben

  

  

  



Thanks, 

So the isNice function has all the code with the 2 times and. 

and what must i use when a test is false so instead of equals: 
false 

Roelof

  

Re: [Pharo-users] some help to find the bug

[Ben Coman]

On Sun, 16 Dec 2018 at 02:37, Roelof Wobben  wrote:

> Hello,
>
> I have this code :
> https://gist.github.com/RoelofWobben/7c08680797d1d9f84436653a0e4edd3b
> as  my solution to a AoC challenge.
>
>
> But the last test `testIsNice`  is still  outputting the wrong output.
> The right output is :   `ugknbfddgicrmopn ` and `aaa`
>
> Someone who can think with me where I make a thinking error so that the
> right output is seen.
>

You seem to already have fixed that problem, so just some general
feedback...

Your #isNice is an instance method, so you are already inside
a FindNiceStrings object.
So you don't need...
```niceStringsObject := FindNiceStrings new.```
Just use self.

By convention, all #isX methods should return a Boolean
Your ```isNice: aCollection``` method returns a collection. That would be
better renamed #selectNice:

The two #and: messages inside the #select: makes that a bit verbose.
I'd refactor that condition out to its own method, i.e. ```isNice: aWord```
since that was freed up
So you would have:
```
FindNiceStrings  selectNice: aCollection
^ aCollection select: [ :word | self isNice: word ]
```


> self assert: (FindNiceStrings new checkForbiddenParts: string) equals:
true

The "equals: true" part is redundant.

cheers -ben