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

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

New Gforth "qixi" Snapshot

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

Contents

  New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-20 01:58 +0200
    Re: New Gforth "qixi" Snapshot "Alex McDonald" <blog@rivadpm.com> - 2015-08-20 09:41 +0100
      Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-20 14:21 +0200
      Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-20 18:54 +0200
        Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-20 20:12 +0200
    Re: New Gforth "qixi" Snapshot Marc Christiansen <usenetmail@solar-empire.de> - 2015-08-20 20:42 +0200
      Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-20 22:45 +0200
    Re: New Gforth "qixi" Snapshot peter.m.falth@gmail.com - 2015-08-21 11:47 -0700
      Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-21 23:23 +0200
      Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-22 00:28 +0200
        Re: New Gforth "qixi" Snapshot borota@gmail.com - 2015-08-23 10:38 -0700
          Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-23 23:53 +0200
            Re: New Gforth "qixi" Snapshot borota@gmail.com - 2015-08-23 15:25 -0700
              Re: New Gforth "qixi" Snapshot rickman <gnuarm@gmail.com> - 2015-08-23 18:42 -0400
                Re: New Gforth "qixi" Snapshot borota@gmail.com - 2015-08-23 16:43 -0700
                  Re: New Gforth "qixi" Snapshot rickman <gnuarm@gmail.com> - 2015-08-23 19:53 -0400
                    Re: New Gforth "qixi" Snapshot Coos Haak <chforth@hccnet.nl> - 2015-08-24 01:58 +0200
              Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-24 02:05 +0200
                Re: New Gforth "qixi" Snapshot borota@gmail.com - 2015-08-23 18:16 -0700
                  Re: New Gforth "qixi" Snapshot borota@gmail.com - 2015-08-23 18:34 -0700
                    Re: New Gforth "qixi" Snapshot rickman <gnuarm@gmail.com> - 2015-08-23 22:10 -0400
                      Re: New Gforth "qixi" Snapshot borota@gmail.com - 2015-08-23 19:30 -0700
                        Re: New Gforth "qixi" Snapshot Julian Fondren <julian.fondren@gmail.com> - 2015-08-23 20:27 -0700
                          Re: New Gforth "qixi" Snapshot borota@gmail.com - 2015-08-23 21:05 -0700
                            Re: New Gforth "qixi" Snapshot Julian Fondren <julian.fondren@gmail.com> - 2015-08-23 21:20 -0700
                        Re: New Gforth "qixi" Snapshot anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-24 07:10 +0000
                          Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-24 15:17 +0200
                            Re: New Gforth "qixi" Snapshot anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-24 15:21 +0000
                              Re: New Gforth "qixi" Snapshot Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-24 17:36 +0200
                    Re: New Gforth "qixi" Snapshot Julian Fondren <ayrnieu@gmail.com> - 2015-08-23 19:12 -0700
                  Re: New Gforth "qixi" Snapshot rickman <gnuarm@gmail.com> - 2015-08-23 22:10 -0400
                    Re: New Gforth "qixi" Snapshot "Elizabeth D. Rather" <erather@forth.com> - 2015-08-23 22:11 -1000
                      Re: New Gforth "qixi" Snapshot Mark Wills <markwills1970@gmail.com> - 2015-08-24 01:37 -0700
                        Re: New Gforth "qixi" Snapshot rickman <gnuarm@gmail.com> - 2015-08-24 08:57 -0400
                        Re: New Gforth "qixi" Snapshot "Elizabeth D. Rather" <erather@forth.com> - 2015-08-24 11:13 -1000
                          Re: New Gforth "qixi" Snapshot Mark Wills <markwills1970@gmail.com> - 2015-08-25 03:09 -0700
                          Re: New Gforth "qixi" Snapshot borota@gmail.com - 2015-08-25 19:34 -0700
                            Re: New Gforth "qixi" Snapshot "Elizabeth D. Rather" <erather@forth.com> - 2015-08-25 21:38 -1000
                            Re: New Gforth "qixi" Snapshot "HAA" <someone@microsoft.com> - 2015-09-01 21:57 +1000
                              Re: New Gforth "qixi" Snapshot Coos Haak <chforth@hccnet.nl> - 2015-09-01 16:15 +0200
                                Re: New Gforth "qixi" Snapshot "HAA" <someone@microsoft.com> - 2015-09-03 16:05 +1000
                                  Re: New Gforth "qixi" Snapshot dunno <dunno@dunno.dunno> - 2015-09-05 03:25 +0000
                                    Re: New Gforth "qixi" Snapshot "HAA" <someone@microsoft.com> - 2015-09-05 21:33 +1000
                                      Re: New Gforth "qixi" Snapshot dunno <dunno@dunno.dunno> - 2015-09-05 18:07 +0000
              Re: New Gforth "qixi" Snapshot "Elizabeth D. Rather" <erather@forth.com> - 2015-08-23 22:01 -1000
      Re: New Gforth "qixi" Snapshot jkn_gg@nicorp.f9.co.uk - 2015-08-23 05:34 -0700

Page 1 of 3  [1] 2 3  Next page →

#41407 — New Gforth "qixi" Snapshot

I've uploaded a new snapshot of the current git HEAD of Gforth into the 
usual place

https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/ (http works, too)

Apart from the ongoing development, the Windows version contains a few 
changes:

* Gforth is started in a way that HOME points to the actual home directory 
(which in Windows is composed of %HOMEDRIVE% and %HOMEPATH%... WTF?), and 
thus all the user-specific stuff actually goes to your home directory - like 
history and such.

* I've added mintty.exe as terminal, which is clearly superior compared to 
the standard DOS box terminal.  Unfortunately, I haven't found out how to 
get rid of the DOS box Windows launches when it starts mintty (the 
workaround which is in mintty.exe itself only works when mintty.exe is 
inside a Cygwin install).

* I've started to generate bindings for system libraries using SWIG.  The 
first one that compiled on Windows was OpenGL ES.  As WGL is not yet 
generated, you can't open a context to work with it, but it's a start.

* Fixpath during installation now does really fix the search path, before, 
it was broken.  I.e. if you use Gforth outside Cygwin, from cmd.exe, you 
should be able to start it from any other working directory.  Make sure, you 
have set HOME as mentioned above.

If you have Cygwin installed, use the cygwin bindist tarball instead.

-- 
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]

#41413

on 20/08/2015 00:58:36, Bernd Paysan wrote:
> I've uploaded a new snapshot of the current git HEAD of Gforth into
> the usual place
> 
> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/ (http works,
> too)
> 
> Apart from the ongoing development, the Windows version contains a few
> changes:
> 
> * Gforth is started in a way that HOME points to the actual home
> directory (which in Windows is composed of %HOMEDRIVE% and
> %HOMEPATH%... WTF?), and thus all the user-specific stuff actually
> goes to your home directory - like history and such.
> 
> * I've added mintty.exe as terminal, which is clearly superior
> compared to the standard DOS box terminal. Unfortunately, I haven't
> found out how to get rid of the DOS box Windows launches when it
> starts mintty (the workaround which is in mintty.exe itself only works
> when mintty.exe is inside a Cygwin install).

Link (or patch) the PE header as a GUI app. The field is 1 for a console
DOS box, 2 for a DLL and 3 for a GUI.

WORD  
Subsystem 
An enum value indicating what subsystem (user interface type) the
executable expects. This field is only important for EXEs. Important
values include: IMAGE_SUBSYSTEM_NATIVE // Image doesn't require a
subsystem IMAGE_SUBSYSTEM_WINDOWS_GUI  // Use the Windows GUI 
IMAGE_SUBSYSTEM_WINDOWS_CUI  // Run as a console mode application 
                             // When run, the OS creates a console 
                             // window for it, and provides stdin, 
                             // stdout, and stderr file handles

It's probably marked as CUI.


https://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx

> 
> * I've started to generate bindings for system libraries using SWIG.
> The first one that compiled on Windows was OpenGL ES. As WGL is not
> yet generated, you can't open a context to work with it, but it's a
> start.
> 
> * Fixpath during installation now does really fix the search path,
> before, it was broken. I.e. if you use Gforth outside Cygwin, from
> cmd.exe, you should be able to start it from any other working
> directory. Make sure, you have set HOME as mentioned above.
> 
> If you have Cygwin installed, use the cygwin bindist tarball instead.
> 

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

#41417

Alex McDonald wrote:
> Link (or patch) the PE header as a GUI app. The field is 1 for a console
> DOS box, 2 for a DLL and 3 for a GUI.
> 
> WORD
> Subsystem
> An enum value indicating what subsystem (user interface type) the
> executable expects. This field is only important for EXEs. Important
> values include: IMAGE_SUBSYSTEM_NATIVE // Image doesn't require a
> subsystem IMAGE_SUBSYSTEM_WINDOWS_GUI  // Use the Windows GUI
> IMAGE_SUBSYSTEM_WINDOWS_CUI  // Run as a console mode application
>                              // When run, the OS creates a console
>                              // window for it, and provides stdin,
>                              // stdout, and stderr file handles
> 
> It's probably marked as CUI.
> 
> 
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms680339%28v=vs.85%29.aspx

Good idea, I'll try that.  Cygwin compiles everything as CUI.  Since I ship 
my own copy, I can patch that as I like, getting rid of the consoles.

-- 
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]

#41418

Alex McDonald wrote:

> Link (or patch) the PE header as a GUI app. The field is 1 for a console
> DOS box, 2 for a DLL and 3 for a GUI.

mintty.exe is 2 (GUI), the Gforth exes are all 3 (console)... so maybe the 
console pops up when mintty launches Gforth.  Gforth however needs to be a 
console app... that's not the solution.

The problem is that mintty outside the cygwin environment can't find its 
helper app which hides those consoles.

-- 
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]

#41420

Bernd Paysan wrote:
> The problem is that mintty outside the cygwin environment can't find its
> helper app which hides those consoles.

I found a solution: Replace the /bin/cygwin-console-helper.exe string in my 
copy of Cygwin with ./in/cygwin-console-helper.exe, and actually put that 
helper into the "in" subdirectory.  Or just add a few zeros for padding and 
put it just into ./cygwin-console-helper.exe (looks less crazy).

The explanation for this fuckup is inside the fhandler.cc source file:

/* Ugly workaround for Windows 7 and later.

   First try to just attach to any console which may have started this
   app.  If that works use this as our "invisible console".

   This will fail if not started from the command prompt.  In that case, 
start
   a dummy console application in a hidden state so that we can use its 
console
   as our invisible console.  This probably works everywhere but process
   creation is slow and to be avoided if possible so the window station 
method
   is vastly preferred.

   FIXME: This is not completely thread-safe since it creates two 
inheritable
   handles which are known only to this function.  If another thread starts
   a process the new process will inherit these handles.  However, since 
this
   function is currently only called at startup and during exec, it 
shouldn't
   be a big deal.  */

-- 
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]

#41421

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> * I've started to generate bindings for system libraries using SWIG.  The 
> first one that compiled on Windows was OpenGL ES.  As WGL is not yet 
> generated, you can't open a context to work with it, but it's a start.

Where does one get SWIG with forth support? The documentation on
swig.org doesn't list forth as supported and ./configure for the
snapshot says
[...]
checking for swig... /usr/bin/swig
swig error : Unrecognized option -forth
Use 'swig -help' for available options.
configure: WARNING: *** Swig without -forth. The library bindings cannot be built.
[...]

Unsurprisingly swig -help does not list forth :)

This is using SWIG Version 3.0.5 on x86_64-pc-linux-gnu.

Saluton
Marc

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

#41422

Marc Christiansen wrote:

> Bernd Paysan <bernd.paysan@gmx.de> wrote:
>> * I've started to generate bindings for system libraries using SWIG.  The
>> first one that compiled on Windows was OpenGL ES.  As WGL is not yet
>> generated, you can't open a context to work with it, but it's a start.
> 
> Where does one get SWIG with forth support? The documentation on
> swig.org doesn't list forth as supported and ./configure for the
> snapshot says
> [...]
> checking for swig... /usr/bin/swig
> swig error : Unrecognized option -forth
> Use 'swig -help' for available options.
> configure: WARNING: *** Swig without -forth. The library bindings cannot
> be built.
> [...]
> 
> Unsurprisingly swig -help does not list forth :)
> 
> This is using SWIG Version 3.0.5 on x86_64-pc-linux-gnu.

You need Gerald Wodni's fork.

git clone git@github.com:/GeraldWodni/swig.git

-- 
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]

#41444

On Thursday, 20 August 2015 01:58:36 UTC+2, Bernd Paysan  wrote:
> I've uploaded a new snapshot of the current git HEAD of Gforth into the 
> usual place
> 
> https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/ (http works, too)
> 
> Apart from the ongoing development, the Windows version contains a few 
> changes:
> 
> * Gforth is started in a way that HOME points to the actual home directory 
> (which in Windows is composed of %HOMEDRIVE% and %HOMEPATH%... WTF?), and 
> thus all the user-specific stuff actually goes to your home directory - like 
> history and such.
> 
> * I've added mintty.exe as terminal, which is clearly superior compared to 
> the standard DOS box terminal.  Unfortunately, I haven't found out how to 
> get rid of the DOS box Windows launches when it starts mintty (the 
> workaround which is in mintty.exe itself only works when mintty.exe is 
> inside a Cygwin install).
> 

I am interested to understand why you think mintty is clearly superior?

I have been testing many alternatives to the windows console but in the 
end always return to it. What I am really missing is a tabbed interface
I found mintty to display faster but unable to run programs that use
the console API correctly.  

> * I've started to generate bindings for system libraries using SWIG.  The 
> first one that compiled on Windows was OpenGL ES.  As WGL is not yet 
> generated, you can't open a context to work with it, but it's a start.
> 
> * Fixpath during installation now does really fix the search path, before, 
> it was broken.  I.e. if you use Gforth outside Cygwin, from cmd.exe, you 
> should be able to start it from any other working directory.  Make sure, you 
> have set HOME as mentioned above.
> 
> If you have Cygwin installed, use the cygwin bindist tarball instead.

Could it be possible to include also the cygwin dlls in the bindist tarball?

On a company PC you are not always allowed to run installers

Thanks anyway for great work

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]

#41447

peter.m.falth@gmail.com wrote:

> On Thursday, 20 August 2015 01:58:36 UTC+2, Bernd Paysan  wrote:
>> If you have Cygwin installed, use the cygwin bindist tarball instead.
> 
> Could it be possible to include also the cygwin dlls in the bindist
> tarball?

The tarball is for users who have cygwin already installed, and having two 
different cygwin dlls inside one cygwin install is a very bad idea.

Maybe I can pack up another tarball with the dlls and the needed programs.  
However, this requires some testing to make sure it actually works.

> On a company PC you are not always allowed to run installers

-- 
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]

#41450

peter.m.falth@gmail.com wrote:

> I am interested to understand why you think mintty is clearly superior?
> 
> I have been testing many alternatives to the windows console but in the
> end always return to it. What I am really missing is a tabbed interface
> I found mintty to display faster but unable to run programs that use
> the console API correctly.

mintty is for programs originally written for Linux.  These programs all 
don't use the console API much, and especially not "correctly", as they 
actually expect an xterm.  Gforth is such a program.  When you use it in the 
normal console, it doesn't work that well.  In mintty, it works fine.

So as terminal for Gforth, mintty is clearly superior.  It's faster, it 
behaves correctly in corner cases (such as editing lines which are longer 
than the screen width), and it does handle Unicode right.  And it supports 
the typical X style copy&paste, which makes it feel "right", for me at least 
;-).

-- 
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]

#41464

X style like copy&paste is available for windows console too if you enable QuickEdit mode from the left top corner icon. One of the first things I always do when getting a new windows system is enabling that for all console windows, by checking in under Defaults. You can also increase the window width, buffer width, etc. 

I used to have an utility around that was hiding windows based on window class name, etc. It was a few lines of c code. It is surprising run.exe can't hide mintty for some reason. 

On Friday, August 21, 2015 at 5:28:32 PM UTC-5, Bernd Paysan wrote:
> peter...gmail.com wrote:
> 
> > I am interested to understand why you think mintty is clearly superior?
> > 
> > I have been testing many alternatives to the windows console but in the
> > end always return to it. What I am really missing is a tabbed interface
> > I found mintty to display faster but unable to run programs that use
> > the console API correctly.
> 
> mintty is for programs originally written for Linux.  These programs all 
> don't use the console API much, and especially not "correctly", as they 
> actually expect an xterm.  Gforth is such a program.  When you use it in the 
> normal console, it doesn't work that well.  In mintty, it works fine.
> 
> So as terminal for Gforth, mintty is clearly superior.  It's faster, it 
> behaves correctly in corner cases (such as editing lines which are longer 
> than the screen width), and it does handle Unicode right.  And it supports 
> the typical X style copy&paste, which makes it feel "right", for me at least 
> ;-).
> 
> -- 
> 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]

#41468

borota@gmail.com wrote:
> I used to have an utility around that was hiding windows based on window
> class name, etc. It was a few lines of c code. It is surprising run.exe
> can't hide mintty for some reason.

That's because mintty isn't a console app, but runs another console app, 
which needs to attach to a console, and starting with Windows 7, doing so 
lets a console pop up.

To hide that, cygwin1.dll has a function, which is calling /bin/cygwin-
console-helper.exe, and that creates a hidden, attachable console 
(apparently, that has to be done by a program, which seems to be running in 
the background).  It's not just hiding the window, it's making the console 
completely invisble.

To allow this to work, this cygwin-console-helper.exe must be in /bin.  Easy 
within a cygwin installation (the root is the install directory), but I had 
to find out that the root is in "Program Files".  If I install a bin 
directory here, and put the helper there, it works.

-- 
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]

#41469

Nice you got it working.

By the way, is it OK in Forth world that after some user(beginner) triggered errors, to have not even the most basic operations work any longer?

5 dup * . 19  ok

That's with the snapshot I just downloaded - I was consistently getting that until I restarted GForth.

I am trying to get my head around Forth people point of view that crashes/access violation errors/lost work/errors like this? are ok when developing. But it's still hard to get used to it, given that the the tools that I am using for work, that pretty much never happens. It's hard not to feel like time has been turned back when immersing myself into Forth world...

On Sunday, August 23, 2015 at 4:53:06 PM UTC-5, Bernd Paysan wrote:
> > I used to have an utility around that was hiding windows based on window
> > class name, etc. It was a few lines of c code. It is surprising run.exe
> > can't hide mintty for some reason.
> 
> That's because mintty isn't a console app, but runs another console app, 
> which needs to attach to a console, and starting with Windows 7, doing so 
> lets a console pop up.
> 
> To hide that, cygwin1.dll has a function, which is calling /bin/cygwin-
> console-helper.exe, and that creates a hidden, attachable console 
> (apparently, that has to be done by a program, which seems to be running in 
> the background).  It's not just hiding the window, it's making the console 
> completely invisble.
> 
> To allow this to work, this cygwin-console-helper.exe must be in /bin.  Easy 
> within a cygwin installation (the root is the install directory), but I had 
> to find out that the root is in "Program Files".  If I install a bin 
> directory here, and put the helper there, it works.
> 
> -- 
> 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]

#41470

On 8/23/2015 6:25 PM, borota@gmail.com wrote:
> Nice you got it working.
>
> By the way, is it OK in Forth world that after some user(beginner) triggered errors, to have not even the most basic operations work any longer?
>
> 5 dup * . 19  ok
>
> That's with the snapshot I just downloaded - I was consistently getting that until I restarted GForth.
>
> I am trying to get my head around Forth people point of view that crashes/access violation errors/lost work/errors like this? are ok when developing. But it's still hard to get used to it, given that the the tools that I am using for work, that pretty much never happens. It's hard not to feel like time has been turned back when immersing myself into Forth world...

Maybe I am not following what you are saying, but you *do* realize your 
system is in base 16 (hex), right?

-- 

Rick

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

#41471

I have never done everything in relation to setting the base to 16.
I have .gforth-history to prove it, at least as far as my Forth knowledge go.
I am not feeling too well due to a cold/flu so maybe I am a bit more
negative than I should be :)

On Sunday, August 23, 2015 at 5:42:31 PM UTC-5, rickman wrote:

> > Nice you got it working.
> >
> > By the way, is it OK in Forth world that after some user(beginner) triggered errors, to have not even the most basic operations work any longer?
> >
> > 5 dup * . 19  ok
> >
> > That's with the snapshot I just downloaded - I was consistently getting that until I restarted GForth.
> >
> > I am trying to get my head around Forth people point of view that crashes/access violation errors/lost work/errors like this? are ok when developing. But it's still hard to get used to it, given that the the tools that I am using for work, that pretty much never happens. It's hard not to feel like time has been turned back when immersing myself into Forth world...
> 
> Maybe I am not following what you are saying, but you *do* realize your 
> system is in base 16 (hex), right?
> 
> -- 
> 
> Rick

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

#41472

On 8/23/2015 7:43 PM, borota@gmail.com wrote:
> I have never done everything in relation to setting the base to 16.
> I have .gforth-history to prove it, at least as far as my Forth knowledge go.
> I am not feeling too well due to a cold/flu so maybe I am a bit more
> negative than I should be :)
>
> On Sunday, August 23, 2015 at 5:42:31 PM UTC-5, rickman wrote:
>
>>> Nice you got it working.
>>>
>>> By the way, is it OK in Forth world that after some user(beginner) triggered errors, to have not even the most basic operations work any longer?
>>>
>>> 5 dup * . 19  ok
>>>
>>> That's with the snapshot I just downloaded - I was consistently getting that until I restarted GForth.
>>>
>>> I am trying to get my head around Forth people point of view that crashes/access violation errors/lost work/errors like this? are ok when developing. But it's still hard to get used to it, given that the the tools that I am using for work, that pretty much never happens. It's hard not to feel like time has been turned back when immersing myself into Forth world...
>>
>> Maybe I am not following what you are saying, but you *do* realize your
>> system is in base 16 (hex), right?
>>
>> --
>>
>> Rick

It would be nice if you didn't top post for sure.  But check the base. 
I don't know what code you are using, but the base might be getting 
changed inside some of the code you are using.  First, check the 
variable to see if it is 16.

-- 

Rick

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

#41473

Op Sun, 23 Aug 2015 19:53:30 -0400 schreef rickman:

> On 8/23/2015 7:43 PM, borota@gmail.com wrote:
>> I have never done everything in relation to setting the base to 16.
>> I have .gforth-history to prove it, at least as far as my Forth knowledge go.
>> I am not feeling too well due to a cold/flu so maybe I am a bit more
>> negative than I should be :)
>>
>> On Sunday, August 23, 2015 at 5:42:31 PM UTC-5, rickman wrote:
>>
>>>> Nice you got it working.
>>>>
>>>> By the way, is it OK in Forth world that after some user(beginner) triggered errors, to have not even the most basic operations work any longer?
>>>>
>>>> 5 dup * . 19  ok
>>>>
>>>> That's with the snapshot I just downloaded - I was consistently getting that until I restarted GForth.
>>>>
>>>> I am trying to get my head around Forth people point of view that crashes/access violation errors/lost work/errors like this? are ok when developing. But it's still hard to get used to it, given that the the tools that I am using for work, that pretty much never happens. It's hard not to feel like time has been turned back when immersing myself into Forth world...
>>>
>>> Maybe I am not following what you are saying, but you *do* realize your
>>> system is in base 16 (hex), right?
>>>
>>> --
>>>
>>> Rick
> 
> It would be nice if you didn't top post for sure.  But check the base. 
> I don't know what code you are using, but the base might be getting 
> changed inside some of the code you are using.  First, check the 
> variable to see if it is 16.

Good advise, but remember,
  base @ .
always prints 10  ;-(
try instead
  10 1- .
If you still see F then something is wrong, 9 would be normal.

I don't see any problem:

$ gforth
Gforth 0.7.9_20150820, Copyright (C) 1995-2015 Free Software Foundation,
Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
5 dup * . 25  ok

groet Coos

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

#41475

borota@gmail.com wrote:

> Nice you got it working.
> 
> By the way, is it OK in Forth world that after some user(beginner)
> triggered errors, to have not even the most basic operations work any
> longer?
> 
> 5 dup * . 19  ok

Ok, as rickman figured out quickly: You are in hex now.  Unless you put 
yourself there and then produced an error, you shouldn't get into hex mode 
by accident.  If you do, it's probably a bug.

> That's with the snapshot I just downloaded - I was consistently getting
> that until I restarted GForth.

Normally, you shouldn't.  What kind of user-triggered error was there 
before?

It helps to reproduce the error, when I know what you exactly did between 
"work" and "doesn't work".

-- 
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]

#41477

It looks like the issue is reproducible on my machine.
Where should I send you .gforth-history file?

5 dup * . 19  ok
base @ . 10  ok


On Sunday, August 23, 2015 at 7:05:37 PM UTC-5, Bernd Paysan wrote:

> 
> > Nice you got it working.
> > 
> > By the way, is it OK in Forth world that after some user(beginner)
> > triggered errors, to have not even the most basic operations work any
> > longer?
> > 
> > 5 dup * . 19  ok
> 
> Ok, as rickman figured out quickly: You are in hex now.  Unless you put 
> yourself there and then produced an error, you shouldn't get into hex mode 
> by accident.  If you do, it's probably a bug.
> 
> > That's with the snapshot I just downloaded - I was consistently getting
> > that until I restarted GForth.
> 
> Normally, you shouldn't.  What kind of user-triggered error was there 
> before?
> 
> It helps to reproduce the error, when I know what you exactly did between 
> "work" and "doesn't work".
> 
> -- 
> 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]

#41478

4 dup * . 10  ok
it looks like the system is indeed using 16 base to do computations, even though base variable reports 10.

On Sunday, August 23, 2015 at 8:16:55 PM UTC-5, bor...@gmail.com wrote:
> It looks like the issue is reproducible on my machine.
> Where should I send you .gforth-history file?
> 
> 5 dup * . 19  ok
> base @ . 10  ok
> 
> 
> On Sunday, August 23, 2015 at 7:05:37 PM UTC-5, Bernd Paysan wrote:
> 
> > 
> > > Nice you got it working.
> > > 
> > > By the way, is it OK in Forth world that after some user(beginner)
> > > triggered errors, to have not even the most basic operations work any
> > > longer?
> > > 
> > > 5 dup * . 19  ok
> > 
> > Ok, as rickman figured out quickly: You are in hex now.  Unless you put 
> > yourself there and then produced an error, you shouldn't get into hex mode 
> > by accident.  If you do, it's probably a bug.
> > 
> > > That's with the snapshot I just downloaded - I was consistently getting
> > > that until I restarted GForth.
> > 
> > Normally, you shouldn't.  What kind of user-triggered error was there 
> > before?
> > 
> > It helps to reproduce the error, when I know what you exactly did between 
> > "work" and "doesn't work".
> > 
> > -- 
> > 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 3  [1] 2 3  Next page →

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

csiph-web