Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #41507 > unrolled thread

Another Gforth snapshot

Back to article view | Back to comp.lang.forth

Contents

  Another Gforth snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-25 01:50 +0200
    Re: Another Gforth snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-25 02:12 +0200
    Re: Another Gforth snapshot peter.m.falth@gmail.com - 2015-08-25 13:57 -0700
      Re: Another Gforth snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-26 01:46 +0200
        Re: Another Gforth snapshot peter.m.falth@gmail.com - 2015-08-25 23:56 -0700
          Re: Another Gforth snapshot mhx@iae.nl - 2015-08-26 00:49 -0700
        Re: Another Gforth snapshot anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-26 07:57 +0000
          Re: Another Gforth snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-26 15:26 +0200
            Re: Another Gforth snapshot anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-26 16:04 +0000
              Re: Another Gforth snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-27 01:18 +0200
    Re: Another Gforth snapshot Greg <borota@gmail.com> - 2015-08-25 20:20 -0700
      Re: Another Gforth snapshot anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-26 09:03 +0000
    Re: Another Gforth snapshot Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-27 11:29 +0100
      Re: Another Gforth snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-27 15:17 +0200
        Re: Another Gforth snapshot Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-08-27 19:54 +0100
          Re: Another Gforth snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-28 04:06 +0200
          Re: Another Gforth snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-28 04:16 +0200
    Re: Another Gforth snapshot mhx@iae.nl - 2015-11-28 03:12 -0800
      Re: Another Gforth snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-28 17:23 +0100
      Re: Another Gforth snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-28 22:11 +0100
        Re: Another Gforth snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-29 01:00 +0100
          Re: Another Gforth snapshot mhx@iae.nl - 2015-11-28 17:11 -0800
            Re: Another Gforth snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-29 03:07 +0100

Page 1 of 2  [1] 2  Next page →

#41507 — Another Gforth snapshot

In the usual place, date code 20150825:

https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/

This time, there's also a 32 bit executable for Windows (for those with 
older computers), and for people who like to just unpack the bindist tarball 
(without actually installing Cygwin), there 's a gforth...-dll.tar.gz which 
contains the necessary Cygwin dlls to run it.  Please report back if that 
works.

I think we considered all reports received from the last snapshot.  I've 
also generated gdi32 and user32 bindings for Windows, so load (historical 
misnomer - *all* foreign function interfaces live in unix/) unix/gdi.fs and 
unix/user.fs; maybe I'll move that to another subdirectory like win/ or so.  
Only the wide char versions of the string stuff is loaded; in utf16.fs you 
find a conversion utility, where >UTF16 creates an UTF16 string ("addr u" on 
stack, zero terminated, so ready for Windows if you just drop the "u"), and 
>UTF8 converts UTF16 strings back to UTF-8 (you need to scan for the 
terminating 0 first; I forgot to add that).  16 buffers exist, so you can 
create several strings and then pass them to Windows.  This code handles 
surrogates, but doesn't check for surrogate errors.

I've only played with trivial functions like IsCharAlpha, so please try.

Due to the fact that the Windows API has some name conflicts between upper 
and lower case, the two vocabularies GDI32 and USER32 are case sensitive.  
So you can only call rightcased Windows API functions.  That may be a bit of 
a surprise given that Gforth otherwise is case insensitive ;-).

Ob-GNU-project-disclaimer: despite Gforth is available for Windows, we do 
not encourage anybody to install and run non-free software such as Windows.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [next] | [standalone]

#41508

Bernd Paysan wrote:

> Ob-GNU-project-disclaimer: despite Gforth is available for Windows, we do
> not encourage anybody to install and run non-free software such as
> Windows.

Another disclaimer: The -dll.tar.gz files certainly are all free software, 
you can download the corresponding source code and licenses with the Cygwin 
installer.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#41523

On Tuesday, 25 August 2015 01:50:38 UTC+2, Bernd Paysan  wrote:
> In the usual place, date code 20150825:
> 
> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/
> 
> This time, there's also a 32 bit executable for Windows (for those with 
> older computers), and for people who like to just unpack the bindist tarball 
> (without actually installing Cygwin), there 's a gforth...-dll.tar.gz which 
> contains the necessary Cygwin dlls to run it.  Please report back if that 
> works.
 
Many Thanks, this works without problem

There is another problem, also present in the snapshot from a few days ago.
The commandline history do not work when gforth is run directly from cmd.exe
It works when run in cygwin. The problem is the s" ~/.gforth-history" in
gforth-history. It is not recognized as a valid filename.


> I think we considered all reports received from the last snapshot.  I've 
> also generated gdi32 and user32 bindings for Windows, so load (historical 
> misnomer - *all* foreign function interfaces live in unix/) unix/gdi.fs and 
> unix/user.fs; maybe I'll move that to another subdirectory like win/ or so.  
> Only the wide char versions of the string stuff is loaded; in utf16.fs you 
> find a conversion utility, where >UTF16 creates an UTF16 string ("addr u" on 
> stack, zero terminated, so ready for Windows if you just drop the "u"), and 
> >UTF8 converts UTF16 strings back to UTF-8 (you need to scan for the 
> terminating 0 first; I forgot to add that).  16 buffers exist, so you can 
> create several strings and then pass them to Windows.  This code handles 
> surrogates, but doesn't check for surrogate errors.
 
You need to execute set-encoding-utf-8 for the conversion to work.
The conversion is wrong and the stack is filled with unused addresses.

Should that not have been set automatically while loading the utility?

Do you really need any other encoding than utf8?

I have only that on my forths. They work internally with utf8, expect input
in utf8 and give all out put in it. In windows I internally before a
systemcall change to utf16 but that is invisible for the user.

Peter

> I've only played with trivial functions like IsCharAlpha, so please try.
> 
> Due to the fact that the Windows API has some name conflicts between upper 
> and lower case, the two vocabularies GDI32 and USER32 are case sensitive.  
> So you can only call rightcased Windows API functions.  That may be a bit of 
> a surprise given that Gforth otherwise is case insensitive ;-).
> 
> Ob-GNU-project-disclaimer: despite Gforth is available for Windows, we do 
> not encourage anybody to install and run non-free software such as Windows.
> 
> -- 
> Bernd Paysan
> "If you want it done right, you have to do it yourself"
> net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
> http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#41528

peter.m.falth@gmail.com wrote:

> On Tuesday, 25 August 2015 01:50:38 UTC+2, Bernd Paysan  wrote:
> Many Thanks, this works without problem
> 
> There is another problem, also present in the snapshot from a few days
> ago. The commandline history do not work when gforth is run directly from
> cmd.exe It works when run in cygwin. The problem is the s"
> ~/.gforth-history" in gforth-history. It is not recognized as a valid
> filename.

Yes, you have to define the environment variable $HOME, and it has to point 
to a user-writable directory.  I probably should make a workaround for 
Windows to check if $HOME is present (e.g. inside Cygwin), and then use it, 
and if not, use HOMEDRIVE and HOMEPATH to construct a valid $HOME.  We have 
some workarounds already in place (using $TEMP and $TMP if no $HOME is 
defined), but when you have cygwin installed, the situation is worse: $HOME 
is defined, but relatively to the cygwin root.  So I also need to check if 
it actually exists...

> You need to execute set-encoding-utf-8 for the conversion to work.
> The conversion is wrong and the stack is filled with unused addresses.

The latter means that something in the fixed-width handling doesn't work...

> Should that not have been set automatically while loading the utility?
> 
> Do you really need any other encoding than utf8?

Sometimes, Latin-1 is needed (legacy stuff).  That's however another 
artefact of not using Cygwin but cmd.exe: $LANG is undefined.  That should 
default to UTF-8 in Cygwin.

> I have only that on my forths. They work internally with utf8, expect
> input in utf8 and give all out put in it. In windows I internally before a
> systemcall change to utf16 but that is invisible for the user.

We could do that in the C bindings, too; at the moment, it's just a pointer 
passed to C without implicit conversion to anything.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#41541

On Wednesday, 26 August 2015 01:46:36 UTC+2, Bernd Paysan  wrote:
> peter.m.falth@gmail.com wrote:
> 
> > On Tuesday, 25 August 2015 01:50:38 UTC+2, Bernd Paysan  wrote:
> > Many Thanks, this works without problem
> > 
> > There is another problem, also present in the snapshot from a few days
> > ago. The commandline history do not work when gforth is run directly from
> > cmd.exe It works when run in cygwin. The problem is the s"
> > ~/.gforth-history" in gforth-history. It is not recognized as a valid
> > filename.
> 
> Yes, you have to define the environment variable $HOME, and it has to point 
> to a user-writable directory.  I probably should make a workaround for 
> Windows to check if $HOME is present (e.g. inside Cygwin), and then use it, 
> and if not, use HOMEDRIVE and HOMEPATH to construct a valid $HOME.  We have 
> some workarounds already in place (using $TEMP and $TMP if no $HOME is 
> defined), but when you have cygwin installed, the situation is worse: $HOME 
> is defined, but relatively to the cygwin root.  So I also need to check if 
> it actually exists...
> 
> > You need to execute set-encoding-utf-8 for the conversion to work.
> > The conversion is wrong and the stack is filled with unused addresses.
> 
> The latter means that something in the fixed-width handling doesn't work...
> 
> > Should that not have been set automatically while loading the utility?
> > 
> > Do you really need any other encoding than utf8?
> 
> Sometimes, Latin-1 is needed (legacy stuff).  That's however another 
> artefact of not using Cygwin but cmd.exe: $LANG is undefined.  That should 
> default to UTF-8 in Cygwin.
> 
> > I have only that on my forths. They work internally with utf8, expect
> > input in utf8 and give all out put in it. In windows I internally before a
> > systemcall change to utf16 but that is invisible for the user.
> 
> We could do that in the C bindings, too; at the moment, it's just a pointer 
> passed to C without implicit conversion to anything.

That is what I do in my latest effort of a 64 bit forth. I have 2 wrapper
libraries, one for windows and one for linux. They are written in C and 
take care of all conversations. In fact now the forth image is identical
on both platforms, they even run at he same address, all differences 
are taken care of by the libraries.

Peter
 
> -- 
> Bernd Paysan
> "If you want it done right, you have to do it yourself"
> net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
> http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#41543

On Wednesday, August 26, 2015 at 8:56:52 AM UTC+2, peter....@gmail.com wrote:
> On Wednesday, 26 August 2015 01:46:36 UTC+2, Bernd Paysan  wrote:
> > peter.m.falth@gmail.com wrote:

> That is what I do in my latest effort of a 64 bit forth. I have 2 wrapper
> libraries, one for windows and one for linux. They are written in C and 
> take care of all conversations. In fact now the forth image is identical
> on both platforms, they even run at he same address, all differences 
> are taken care of by the libraries.

This is also how iForth does it. To make it run on OSX 
the C server had to be slightly modified. The Windows 
server is very different from the Linux one, but I guess
it can be backported quite easily from Linux by now.

-marcel

[toc] | [prev] | [next] | [standalone]

#41545

Bernd Paysan <bernd.paysan@gmx.de> writes:
>peter.m.falth@gmail.com wrote:
>> I have only that on my forths. They work internally with utf8, expect
>> input in utf8 and give all out put in it. In windows I internally before a
>> systemcall change to utf16 but that is invisible for the user.
>
>We could do that in the C bindings, too; at the moment, it's just a pointer 
>passed to C without implicit conversion to anything.

It can be done in the same call as the conversion to zero-terminated
strings (how are these UTF16 strings terminated, BTW?).

Doing it automatically (with SWIG) is not possible, because the C
headers don't contain information on whether the pointers point to
input strings or to output buffers (or something that serves as both).
So we need to provide that information manually.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#41557

Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>peter.m.falth@gmail.com wrote:
>>> I have only that on my forths. They work internally with utf8, expect
>>> input in utf8 and give all out put in it. In windows I internally before
>>> a systemcall change to utf16 but that is invisible for the user.
>>
>>We could do that in the C bindings, too; at the moment, it's just a
>>pointer passed to C without implicit conversion to anything.
> 
> It can be done in the same call as the conversion to zero-terminated
> strings (how are these UTF16 strings terminated, BTW?).

By a zero wide-char, i.e. by \u0000.

> Doing it automatically (with SWIG) is not possible, because the C
> headers don't contain information on whether the pointers point to
> input strings or to output buffers (or something that serves as both).
> So we need to provide that information manually.

As long as the C declaration had "const" for those strings that aren't used 
as return values, it could be done.

Microsoft uses a defined type, LPCSTR (or LPCWSTR for wide char, they don't 
like C naming conventions) to specify strings only used as input, so that 
information can be automatically extracted from the C headers.  Other, read-
write (or write-only) strings are LPSTR and LPWSTR.

Swig distinguishes between const char * and char *, (and of course also 
const w_char * and w_char *), so mapping those to different Forth types is 
pretty easy.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#41562

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Doing it automatically (with SWIG) is not possible, because the C
>> headers don't contain information on whether the pointers point to
>> input strings or to output buffers (or something that serves as both).
>> So we need to provide that information manually.
>
>As long as the C declaration had "const" for those strings that aren't used 
>as return values, it could be done.

There is no requirement to use "const" and therefore no guarantee that
it is used in that way.  And even if it were, there is no guarantee
that a "const char *" refers to a string.

>Microsoft uses a defined type, LPCSTR (or LPCWSTR for wide char, they don't 
>like C naming conventions) to specify strings only used as input, so that 
>information can be automatically extracted from the C headers.  Other, read-
>write (or write-only) strings are LPSTR and LPWSTR.

That sounds more promising.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#41572

Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>Anton Ertl wrote:
>>> Doing it automatically (with SWIG) is not possible, because the C
>>> headers don't contain information on whether the pointers point to
>>> input strings or to output buffers (or something that serves as both).
>>> So we need to provide that information manually.
>>
>>As long as the C declaration had "const" for those strings that aren't
>>used as return values, it could be done.
> 
> There is no requirement to use "const" and therefore no guarantee that
> it is used in that way.  And even if it were, there is no guarantee
> that a "const char *" refers to a string.

SWIG makes that assumption throughout for other languages.  If you happen to 
have a library which doesn't, just #define const as nothing, so SWIG won't 
see it, and map the type to a normal char * (which then is just an address).  
And for derived types, you can apply typemaps to get what you want.  I'm 
pretty sure you can deal with const GLubyte * in OpenGL (which is *not* a 
string).

>>Microsoft uses a defined type, LPCSTR (or LPCWSTR for wide char, they
>>don't like C naming conventions) to specify strings only used as input, so
>>that
>>information can be automatically extracted from the C headers.  Other,
>>read- write (or write-only) strings are LPSTR and LPWSTR.
> 
> That sounds more promising.

As Swig does a good job for other languages to translate the strings 
correctly, the assumption Swig makes about const char * seems to hold, most 
of the time.

C's string stuff is a mess, but people seem to be able to deal with it.  
There may be some exceptions that you'll have to deal with.  
XCreateBitmapFromData takes a byte array as const char *, which doesn't need 
any conversion.  There are some obvious exceptions in Xlib.h.

Xlib.h is probably the worst case here, it has strings before an int, and 
byte arrays with size following, and it doesn't use size_t for the sizes, 
but sometimes int, sometimes unsigned int.  Overall, however, the majority 
of cases where a const char * is followed by an integer, it's binary data or 
a string in Forth string format, which we don't need to convert.

Therefore, a relatively small patch script is sufficient.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#41536

On Monday, August 24, 2015 at 6:50:38 PM UTC-5, Bernd Paysan wrote:
> In the usual place, date code 20150825:
> 
> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/
> 
> This time, there's also a 32 bit executable for Windows (for those with 
> older computers), and for people who like to just unpack the bindist tarball 
> (without actually installing Cygwin), there 's a gforth...-dll.tar.gz which 
> contains the necessary Cygwin dlls to run it.  Please report back if that 
> works.
> 
> I think we considered all reports received from the last snapshot.  I've 
> also generated gdi32 and user32 bindings for Windows, so load (historical 
> misnomer - *all* foreign function interfaces live in unix/) unix/gdi.fs and 
> unix/user.fs; maybe I'll move that to another subdirectory like win/ or so.  
> Only the wide char versions of the string stuff is loaded; in utf16.fs you 
> find a conversion utility, where >UTF16 creates an UTF16 string ("addr u" on 
> stack, zero terminated, so ready for Windows if you just drop the "u"), and 
> >UTF8 converts UTF16 strings back to UTF-8 (you need to scan for the 
> terminating 0 first; I forgot to add that).  16 buffers exist, so you can 
> create several strings and then pass them to Windows.  This code handles 
> surrogates, but doesn't check for surrogate errors.
> 
> I've only played with trivial functions like IsCharAlpha, so please try.
> 
> Due to the fact that the Windows API has some name conflicts between upper 
> and lower case, the two vocabularies GDI32 and USER32 are case sensitive.  
> So you can only call rightcased Windows API functions.  That may be a bit of 
> a surprise given that Gforth otherwise is case insensitive ;-).
> 
> Ob-GNU-project-disclaimer: despite Gforth is available for Windows, we do 
> not encourage anybody to install and run non-free software such as Windows.
> 
> -- 
> Bernd Paysan
> "If you want it done right, you have to do it yourself"
> net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
> http://bernd-paysan.de/

Nice. Thanks for the quick fixes:
1) Console window is no longer visble.

2) By stealing gdb from cygwin
base @ 1- . 9  ok
see nip
Code nip
   0x0000000100402f98 <gforth_engine+7864>:     mov    %rbx,0x30(%rsi)
   0x0000000100402f9c <gforth_engine+7868>:     mov    (%r15),%rdx
   0x0000000100402f9f <gforth_engine+7871>:     mov    %r15,%rax
   0x0000000100402fa2 <gforth_engine+7874>:     lea    0x8(%r15),%r15
   0x0000000100402fa6 <gforth_engine+7878>:     add    $0x8,%rbx
   0x0000000100402faa <gforth_engine+7882>:     mov    %rdx,0x8(%rax)
   0x0000000100402fae <gforth_engine+7886>:     mov    -0x8(%rbx),%rdx
   0x0000000100402fb2 <gforth_engine+7890>:     mov    %rdx,%rax
   0x0000000100402fb5 <gforth_engine+7893>:     jmpq   *%rax
end-code
 ok
base @ 1- . 9  ok

Note though that if you change the default installation path, installation
fails to finish due to sh being expected to still be at the default path.

Also I am trying to have locate work with either cygwin emacs or native
emacs. I am getting this:
locate recognizer
*ERROR*: Symbol's function definition is void: forth-find-tag ok
Any idea?

[toc] | [prev] | [next] | [standalone]

#41548

Greg <borota@gmail.com> writes:
>2) By stealing gdb from cygwin
>base @ 1- . 9  ok
>see nip
>Code nip
>   0x0000000100402f98 <gforth_engine+7864>:     mov    %rbx,0x30(%rsi)
>   0x0000000100402f9c <gforth_engine+7868>:     mov    (%r15),%rdx
>   0x0000000100402f9f <gforth_engine+7871>:     mov    %r15,%rax
>   0x0000000100402fa2 <gforth_engine+7874>:     lea    0x8(%r15),%r15
>   0x0000000100402fa6 <gforth_engine+7878>:     add    $0x8,%rbx
>   0x0000000100402faa <gforth_engine+7882>:     mov    %rdx,0x8(%rax)
>   0x0000000100402fae <gforth_engine+7886>:     mov    -0x8(%rbx),%rdx
>   0x0000000100402fb2 <gforth_engine+7890>:     mov    %rdx,%rax
>   0x0000000100402fb5 <gforth_engine+7893>:     jmpq   *%rax
>end-code
> ok
>base @ 1- . 9  ok

That probably already worked before, now it behaves nicer when gdb is
not available.

>Also I am trying to have locate work with either cygwin emacs or native
>emacs. I am getting this:
>locate recognizer
>*ERROR*: Symbol's function definition is void: forth-find-tag ok
>Any idea?

Emacs needs gforth.el or gforth.elc loaded.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#41576

On 25/08/2015 00:50, Bernd Paysan wrote:
> In the usual place, date code 20150825:
>
> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/
>
> This time, there's also a 32 bit executable for Windows (for those with
> older computers), and for people who like to just unpack the bindist tarball
> (without actually installing Cygwin), there 's a gforth...-dll.tar.gz which
> contains the necessary Cygwin dlls to run it.  Please report back if that
> works.
>

I tried installing gforth-0.7.9_20150825.exe which is the only Win 32 
self-installing executable dated 25 Aug 2015 I could find and it failed 
with sh.exe displaying the following error message

"The procedure entry point __ctype_ptr__ could not be located in the 
dynamic link library cygwin1.dll"


-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#41577

Gerry Jackson wrote:
> I tried installing gforth-0.7.9_20150825.exe which is the only Win 32
> self-installing executable dated 25 Aug 2015 I could find and it failed
> with sh.exe displaying the following error message
> 
> "The procedure entry point __ctype_ptr__ could not be located in the
> dynamic link library cygwin1.dll"

Strange.  According to nm, this symbol is in cygwin1.dll.  Do you have by 
chance another, older cygwin1.dll somewhere in you path?

cygwin1.dll is extremely prone of DLL hell :-(.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#41580

On 27/08/2015 14:17, Bernd Paysan wrote:
> Gerry Jackson wrote:
>> I tried installing gforth-0.7.9_20150825.exe which is the only Win 32
>> self-installing executable dated 25 Aug 2015 I could find and it failed
>> with sh.exe displaying the following error message
>>
>> "The procedure entry point __ctype_ptr__ could not be located in the
>> dynamic link library cygwin1.dll"
>
> Strange.  According to nm, this symbol is in cygwin1.dll.  Do you have by
> chance another, older cygwin1.dll somewhere in you path?
>
> cygwin1.dll is extremely prone of DLL hell :-(.
>

When I looked at the path there were some old GForth directories there 
that probably had an old copy. Presumably GForth installation set the 
path to include those some time ago? When I cleared the path and tried 
again it overcame the above problem - so thanks for that.

Incidentally I had to install GForth into C:\Program Files\ otherwise I 
received this error message when I tried installation on another drive:

Gforth postinstall started
./gforthmi.sh: line 1: /bin/sh.exe: No such file or directory
Gforth postinstall failed!
An error occured, pess return to quit

(Presumably one of your messages, if so there are a couple of typos 
there :-)

Anyway all is well now - many thanks

Apart from 1 minor problem (see below), that 32 bit GForth runs all the 
Forth 2012 test programs, the only system (apart from mine) that does 
so. Other major systems either lack some Forth 2012 words or crash - I 
may not have the latest versions of some of course.

The minor problem: Forth 2012 states that "at least sixteen locals in a
definition" shall be supported. This implies that the environment query 
#LOCALS should return a number > 15. GForth returns 15.

-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#41583

Gerry Jackson wrote:

> The minor problem: Forth 2012 states that "at least sixteen locals in a
> definition" shall be supported. This implies that the environment query
> #LOCALS should return a number > 15. GForth returns 15.

AFAIK we don't have any real limit, and nobody uses the environmental query.  
But I'll bump that up to 16.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#41584

Gerry Jackson wrote:

> Incidentally I had to install GForth into C:\Program Files\ otherwise I
> received this error message when I tried installation on another drive:

Yes, the /bin directory is now in Program Files; but should go into {app}\..
\bin, whereever that {app} directory is.  I'll try.

Gforth puts its own installation directory into PATH, but can't remove it; 
that's a shortcoming of the path adder script I use in Inno Setup.  Maybe 
there's now something better which will be removed at uninstall.

However, if you just keep old Gforth versions around, this doesn't help.

Adding Gforth to PATH is done so that you can use it from the normal command 
line.  If you want multiple Gforth versions around, please install a 
minimalistic Cygwin, and use the bindist tarball and "make install" from 
that one.  That's gonna install gforth-<version> so that you can call 
different versions.  The setup.exe will never be as good as Gforth within a 
Cygwin installation.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#43895

On Tuesday, August 25, 2015 at 1:50:38 AM UTC+2, Bernd Paysan wrote:
> In the usual place, date code 20150825:
> 
> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/
[..] 
> Please report back if that works.

(I have a full cygwin64 install that is good enough to compile and
run even X-windows.)

When using the self-installing Windows binary a DOS window opens and
I see at least four error messages.
Running (either from the Windows menu or cygwin64) fails.

marcel@me-tarzan /cygdrive/c/Program Files (x86)/gforth64
$ gforth-fast
gforth-fast: cannot open image file gforth.fi in path .:/usr/local/lib/gforth/site-forth:/usr/local/lib/gforth/0.7.9_20150825:/usr/local/share/gforth/0.7.9_20150825:/usr/share/gforth/site-forth:/usr/local/share/gforth/site-forth for reading

Also: 

marcel@me-tarzan /cygdrive/c/Program Files (x86)/gforth64
$ ls /usr/local/lib/
total 0

and 

marcel@me-tarzan /cygdrive/c/Program Files (x86)/gforth64
$ ls -l /usr/local/lib/gforth/site-forth
ls: cannot access /usr/local/lib/gforth/site-forth: No such file or directory


The installer appears to assume something?

I could try the amd64 stuff, but what is *.s2o and *.sig?

-marcel

[toc] | [prev] | [next] | [standalone]

#43901

mhx@iae.nl wrote:

> On Tuesday, August 25, 2015 at 1:50:38 AM UTC+2, Bernd Paysan wrote:
>> In the usual place, date code 20150825:
>> 
>> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/
> [..]
>> Please report back if that works.
> 
> (I have a full cygwin64 install that is good enough to compile and
> run even X-windows.)

Then you probably want the cygwin tarball, as having two cygwin1.dll in 
different places is often the root cause of a lot of problems (DLL hell, it 
works when both versions are identical).

> When using the self-installing Windows binary a DOS window opens and
> I see at least four error messages.

Those would be interesting.

> Running (either from the Windows menu or cygwin64) fails.
> 
> marcel@me-tarzan /cygdrive/c/Program Files (x86)/gforth64
> $ gforth-fast
> gforth-fast: cannot open image file gforth.fi in path
> .:/usr/local/lib/gforth/site-
forth:/usr/local/lib/gforth/0.7.9_20150825:/usr/local/share/gforth/0.7.9_20150825:/usr/share/gforth/site-
forth:/usr/local/share/gforth/site-forth
> for reading

That installer wants to replace the preprogrammed path with the actual path.  
If that fails, you can't use Gforth.

The path content looks somewhat inconsistent, maybe there's a mixup between 
old and new files, and that causes the failure... I'll check that.

> Also:
> 
> marcel@me-tarzan /cygdrive/c/Program Files (x86)/gforth64
> $ ls /usr/local/lib/
> total 0
> 
> and
> 
> marcel@me-tarzan /cygdrive/c/Program Files (x86)/gforth64
> $ ls -l /usr/local/lib/gforth/site-forth
> ls: cannot access /usr/local/lib/gforth/site-forth: No such file or
> directory
> 
> 
> The installer appears to assume something?

It assumes that the just installed .exe files are writeable.  Perhaps you 
capture the error messages.

> I could try the amd64 stuff, but what is *.s2o and *.sig?

A *.sig is a PGP (GnuPG) signature, and a *.s2o is a net2o signature.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#43914

mhx@iae.nl wrote:

> On Tuesday, August 25, 2015 at 1:50:38 AM UTC+2, Bernd Paysan wrote:
>> In the usual place, date code 20150825:
>> 
>> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/
> [..]
>> Please report back if that works.
> 
> (I have a full cygwin64 install that is good enough to compile and
> run even X-windows.)
> 
> When using the self-installing Windows binary a DOS window opens and
> I see at least four error messages.

Ok, I see the problem: launching 64 bit sh.exe from 32 bit programs (PE32) 
doesn't work anymore.  Since the setup.exe installer is a PE32 program, 
installing gforth64 won't work.  The error messages look like this:

fork: can't reserve memory for parent stack 0x600000 – 0x800000, (child has 
0x400000 – 0x600000), Win32 error 487

Since this affects the older gforth64 installers, too, it's probably not a 
new Cygwin64 bug, but a new Windows bug.  Tested with Windows 10 1511.

From a quick look it seems that installing a 32 bit sh.exe in {app}\..\bin 
fixes the problem; this 32 bit sh.exe needs its own set of cygwin dlls 
(fortunately they can stay in {app}\..\bin, and won't conflict with Gforth's 
directory), and it can launch 64 bit Gforth during install successfully.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web