AltME groups: search

got this error from a rebol process launched by another rebol process 
running uniserve:

dyld: Library not loaded: /usr/lib/libncurses.5.4.dylib
Referenced 
from: /bin/bash
Reason: image not found
*** Boot Error 951
What may that Boot Error 951 be?

thank you Anton, but /usr/lib/libncurses.5.4.dylib does exist! After 
a while rebol process launched by main uniserve process show this 
error and then rebol seams to loose ability to read/write files, 
restarting brings everything back to normal,

Rebol []

comment [
	; example usage:
	kernel: load/library %kernel32.dll

 routine-call kernel "MulDiv" [int] [3 [integer!] 2 [integer!] 1 [integer!]] 
 ; == 6
]

routine-call: func [
	library [library!]
	routine-name [string!]
	return-spec [block!]
	arguments [block!] 

 /typed {Arguments is block structure is: [argument-value [datatype] 
 ...]}
	/local routine spec call argument type typed-rule
] [
	spec: make block! length? arguments
	call: make block! (length? arguments) / 2 + 1
	insert call [return routine]
	typed-rule: copy []
	if typed [typed-rule: [set type skip]]
	parse reduce arguments [
		any [
			set argument skip
			typed-rule
			(
				insert/only tail spec 'argument
				insert/only tail spec either typed [
					type
				][
					reduce [type?/word get/any 'argument]
				]
				insert/only tail call get/any 'argument
			)
		]
	]
	insert tail spec [return:]
	insert/only tail spec return-spec
	routine: make routine! spec library routine-name
	do call
]

use [libc zero-char as-rebol-string malloc][
	libc: load/library %/usr/lib/libc.dylib ; osx variable

	zero-char: #"^@"

	as-rebol-string: func [
		[catch]
		s [string!] 
		/local pos
	][

  unless pos: find s zero-char [throw make error! "s is not a c-string"]
		s: head remove/part pos tail s
		replace/all s "\n" newline
		replace/all s "\t" tab
	]
	
	malloc: func [
        size [integer!] "size in bytes"
    ][
        head insert/dup copy {} zero-char size
    ]

	sprintf: func [
		spec {block structure is: [format values ...]}
		/local s
	][
		s: malloc 4096
		insert/only head spec 's
		routine-call libc "sprintf" [int] spec
		as-rebol-string s
	]
	
	printf: func [
		spec {block structure is: [format values ...]}
	][
		print sprintf spec
	]
]

1.0.5 available at: http://www.dobeash.com/download.html


Mac OS X now uses the v2 API and newer dylib path. SQLite/version 
now contains version number as a tuple!

I could patch cgi.r if I was certain that I should use /usr/lib/libc.dylib 
in place of /lib/libc.so.6 or .5

Script: "Cheyenne Web Server" (2-Mar-2011)
Script: "Encap virtual filesystem" (21-Sep-2009)

** Access Error: Cannot open /Users/onetom/rebol/cheyenne-server-read-only/Cheyenne/libc.dylib
** Where: do-cache
** Near: all [
    libc: load/library %libc.dylib

OK, the right path for the Libc is: %/usr/lib/libc.dylib

there was no need for changing the %libc.dylib

I have come across a strange problem with View 2.7.7 on Mac OS X. 
If I load a library, run a function from the library and then put 
the machine into sleep mode, Rebol crashes with a Floating Point 
Exception when the machine wakes up. Here is ahte console session:

>> mylib: load/library %Code/Pascal/libtestlib.dylib
>> add1: make routine! [a[int] return: [int]] mylib "myfunc" 
>> add1 12
== 13
>> Floating point exception


I compiled and tested the library under Windows, put the machine 
to sleep, no problem when it woke up. (I was running Windows as a 
Virtual Box VM).

Any suggestions?

I have found that the problem with OS X View 2.7.7 crashing on wakeup 
was caused by a problem with the dylib. The root of a problem is 
a conflict between the linker on Snow Leopard and Free Pascal (the 
problem didn't exist on Lepoard).


I have a workaround which is to statically link the pascal code into 
a C "wrapper" dylib.

The harm comes from having .dll, .so or .dylib in the Needs lists 
of what would be otherwise portable REBOL modules and scripts.

Doesn't negate my argument. Having them named .rx will mark them 
as extensions, which have a specific calling convention that must 
be supported. Nonetheless, if you do decide to also allow the default 
platform dynamic library naming convention, only allow the name supported 
by the current platform. So no .dll on Linux, no .so on OS X, no 
.dylib on Windows.

simply marking rx/dll/so/dylib as possible extensions for extensions 
sounds perfectly reasonable

Not needlessly - .dylib files don't work on Windows.

They even might, if someone wrote a dylib loader for windows

And keep .dll .so and .dylib as they are now

I want to keep .dll, .so and .dylib files as they are now. That is 
what we write .rx extensions to wrap.

If you want a single platform extension: name it foo.so, use it with 
import %foo.so; if you want a multiplatform extension: create libraries 
foo.so, foo.dll, foo.dylib, import with %foo.rx

just a quick reminder: on osx .dylib and .so are both ok

OK. They're just for convenience though, since every almost dylib 
that is loadable as an extension will have been written specificly 
for that purpose and probably can't be used otherwise, so sticking 
to the .rx filename makes sense.

Andreas, what do you think of this code instead?

append system/options/file-types [%.rx extension]
switch fourth system/version [
	3 [append system/options/file-types [%.dll extension]]

 2 [append system/options/file-types [%.dylib extension %.so extension]]
	4 7 [append system/options/file-types [%.so extension]]
]

switch/default fourth system/version [
	3 [append system/options/file-types [%.rx %.dll extension]]

 2 [append system/options/file-types [%.rx %.dylib %.so extension]]
	4 7 [append system/options/file-types [%.rx %.so extension]]
] [append system/options/file-types [%.rx extension]]

append system/options/file-types switch/default fourth system/version 
[
	3 [[%.rx %.dll extension]]
	2 [[%.rx %.dylib %.so extension]]
	4 7 [[%.rx %.so extension]]
] [[%.rx extension]]

?

Can't sensibly try without e.g. a OSX dylib.

All you have to do to use it, is to import the 'extload module first, 
before you import any native extension. After that, use the generic 
suffix to load extensions.


For example, let's assume you want to load your platform's cURL-binding.* 
extension:

import %extload.r3
import %cURL-binding.rx


On Linux (in the system/platform/1 sense) and FreeBSD, this will 
first attempt to load %cURL-binding.rx and if that fails, %cURL-binding.so.


On Windows, %cURL-binding.rx and %cURL-binding.dll are tried (in 
this order).


On OSX, %cURL-binding.rx, %cURL-binding.dylib and %cURL-binding.so 
are tried (in this order).

here's a personal wishlist:


1. a license for the hostkit, which would allow us to publish and 
distribute patches and custom builds. this would be a necessary precondition 
to bootstrap a healthy hostkit ecosystem (if such a thing is desired).


2. documentation of more hostkit intricacies, such as "documenting 
the boot script build method" mentioned on the priorities page. another 
pet peeve of mine would be documentation on how to add new native 
port types (such as ssl). and fixes (if any) to enable creation of 
such native ports by only touching mezzanines and the host kit.

3. a libr3.dylib built for osx.

Don't forget lib/2.5/libr3.dylib

Doc, is that with .dylib or not?

Defining routines is very flexible, a bit against my simplistic philosophy 
for World, but now it's done. Having e.g. libc (OS X example):

libc: load/library %/usr/lib/libc.dylib

Defining PUTS can be as simple as:

puts: make routine! [
	libc "puts" [
		[string!] pointer
	]
	sint
]

or as full of info and features as:

puts: make routine! [
	"Writes a string to stdout followed by a newline."
	[typecheck]
	libc "puts" [
		string [string!] pointer "String to write to stdout"
	]
	sint integer!
]

In the above example, libc is defined as:

libc: load/library %/usr/lib/libc.dylib