Oxygen Basic
Information => Open Forum => Topic started by: Mike Lobanovsky on October 05, 2014, 05:25:53 PM
-
Hello native English speakers,
Welcome to a completely off-topic thread.
It is a well-known fact that people often mutter to themselves when totally immersed in some work. It is generally believed that muttering helps people concentrate deeper.
So my question is, how would you mutter to yourselves hWnd when typing a function call?
(Be forewarned I'm never going to believe it if you would insist you're calling it eitch-dubl-you-en-dee)
-
Hi Mike,
It is easy using Welsh pronunciation, though I am not a speaker myself. Welsh phonetics are highly consistent, so one can deliver an entire speech without understanding a single word of it. :)
hWnd: pronounced Hoond
-
Morning Charles,
Is that your personal, unique way of muttering it?
(Charles, I've spent the whole night trying to find out why Oxygen's console wouldn't display printf(), fprintf(), etc. output, even though I can easily get correct pointers to msvcrt.dll's _iob[] (that's its internal FILE array) and all the necessary function pointers. MS VC, GCC, DynC and FBSL's BASIC do it easily without any problems with the exact same pointers but not Oxygen. That's very irritating because nanoscheme must use the same function set to print to the console and to disk files. That's what the fprintf family does. Do you know by any chance what might be causing this, er, unusual behavior? :( )
-
Nothing obvious, for sure. Would it be worth creating an emulation of printf, (returning a string). I have some partial models already. Avoiding dependency on MSVCRT.
PS: I seldom listen to my own mutterings :)
-
But why should we be trying to avoid this dependency? CRT is available on all known platforms, and its f... functions have been standard C stream methodology since K&R! printf() is just a castrated fprintf() oriented towards stdout only...
-
I thought MSVCRT was only included with a C compier.
Does it require an initialisation procedure, invisibly implemented by the C compiler ?
http://msdn.microsoft.com/en-us/library/bb918180.aspx
-
CRT is a system library everywhere, Charles. And no, there's no initialization required. You can even get the _iob and function pointers via LoadLibrary/GetProcAddress in any of the languages and call fprintf or printf by pointer, and they would work -- but not in Oxygen. Neither is it a matter of variadic-ity (?) because sscanf() or sprintf() work faultlessly while being similarly variadic.
I think something must be wrong with the console proper. But exactly what it is is slipping me at the moment...
-
I must explore!
sprint_s works:
includepath "$/inc/"
include "console.inc"
extern lib "MSVCRT.dll"
sys _aligned_malloc(sys size, alignment)
sys _aligned_free(sys memblock)
sys sprintf_s(char *buf, sys size, char* format, ...)
end extern
'a=_aligned_malloc 100,8
string s=nuls 1000
sprintf_s s,1000,"%s","Hello World",0
print s
waitkey
But printf does not engage with the console.
-
Got it!
printf will not work in JIT code, but in a binary, you can declare it to be a console application. This changes the SUBSYSTEM flag in the PE fileheader from 2 to 3:
#console
#console
% filename "t.exe"
includepath "$/inc/"
include "RTL32.inc"
include "console.inc"
extern lib "MSVCRT.dll"
sys _aligned_malloc(sys size, alignment)
sys _aligned_free(sys memblock)
sys printf (char *format, ...)
sys sprintf_s(char *buf, sys size, char *format, ...)
end extern
'a=_aligned_malloc 100,8
string s=nuls 1000, t=""
sprintf_s s,1000,"%s%i","Hello World" cr,42
print rtrim s
printf "%s%i\n", "Hello Moon" cr, 24
'waitkey
t=input
-
Yes Charles,
Your investigations are correct. My test script with fprintf() & Co. also works when compiled to a #console app, and that's great.
But this leaves us with the JIT problem in our hands. Fbsl.exe is a GUI program like gxo2.exe yet it allows its BASIC, DynC and DynAsm components to fprintf, printf and PRINT to the console easily. It just responds to the #apptype console directive in the script by opening up its process console that all these functions can print to no matter what components of the language are actually using them.
Can gxo2.exe do the same in response to #console, do you think?
-
How do you make this happen in your JIT environment, Mike? Is it sufficient for the compiler to open a console?
Using sprintf is a good workaround:
sys sprintf_s(char *buf, sys size, char *format, ...)
static char s[1000]
...
sprintf_s s,1000,"%s%i","Hello World" cr,42 : print s
sprintf_s s,1000,"%s%i", cr "Hello Moon" cr, 24 : print s
-
Using sprintf is a good workaround:
From the C world, I wouldn't call sprintf() a workaround. FORMAT in C clothing.
-
It is certainly more versatile.
-
WE DON'T NEED ANY WORKAROUNDS! A WORKAROUND IS IN FACT A CRUTCH AND DOWNRIGHT SURRENDER! I BELIEVE WE CAN KILL THE BEAST IN ITS DEN!
There's absolutely no magic in the creation of FBSL console. Everything goes through AllocConsole(), same as in your Console.inc file.
From the system perspective, FBSL is always a monolithic GUI process. Its dynamically compiled DynC and DynAsm blocks are simply its subroutines that serve the needs of an FBSL script alonside the GCC subroutines of FBSL's virtual machine that execute the mixture of tokenized/bytecoded BASIC code proper. (Not all FBSL's BASIC constructs can be easily bytecoded so FBSL sometimes falls back to incremental interpretation, e.g. in the evaluation frames of For/Next loops.)
DynC and DynAsm blocks are compiled on program load and their entry points are fitted into the framework of an ordinary internal variant-based tree of a user defined function. There is no "external" difference between the tree (i.e. a doubly linked list of arguments, entry and return addresses, and a variant that would store persistently the most recent return value of this function) of an ordinary user defined BASIC function and a function precompiled by any of the two JITs. And the only "internal" difference between them would be that an interpretative BASIC function would make sideways calls to the virtual machine's helper routines to perform its duties while a JIT function would be completely self-sufficient -- sort of "encapsulated".
That said, FBSL would always create an invisible GUI window on launching regardless of the script's #apptype. If the #apptype is GUI (the default) or MDI, the user is supposed to optionally resize and center or otherwise reshape the window to the program's needs, show it and fall through to the Begin Events/End Events block which is a prettified callback for processing the window's messages.
The console is not automatically created in a GUI application. It is created on the fly only if the script hits an unsuppressed warning or untrapped error condition, in which case the console is immediately spawned through the same AllocConsole() and associated text coloration helpers to serve as an stderr device.
In an #apptype console or cgi mode, the console is created automatically via AllocConsole() at app start while the GUI window stays hidden at all times. This is the device where BASIC, C, and Asm code prints to, if needed, utilizing any of the BASIC or C or asm facilities that the programmer wishes, including BASIC PRINTF() and its derivatives, C fprintf() or printf(), or asm calls to any libraries preloaded for that purpose.
Printing occurs automagically: once the process has its console window opened, all printing goes there all by itself regardless of what printing functions are invoked.
If gxo2.exe acts in the same manner, i.e. if JIT compiled code runs within the bounds of gxo2's process as a subroutine, then gxo2.exe should spawn its own console in response to the #console directive in the script. But if it emits precompiled O2 code as a separate process, it should then inject transparently the AllocConsole() lines into the script just before compilation in response to the #console directive.
I hope my explanations are helpful. :)
-
Hi John,
In the meantime, what about you variant of hWnd, please?
-
But if it emits precompiled O2 code as a separate process, it should then inject transparently the AllocConsole() lines into the script just before compilation in response to the #console directive.
You should have a peek at the DLLC code Charles did for console support in a threaded environment. Works great!
-
John,
You feelin' jealous or overlooked or what? Charles asked me how my console works in FBSL and I answered. We are talking about problems with his gxo2.exe, not FBSL or SB that don't have any such problems, thanks God in the former case, and Charles, in the latter.
Charles is a brilliant programmer and I'm absolutely sure gxo2.exe will get eventually improved on too (if only he wouldn't doze off over such workarounds as were suggested here... ;) )
-
You feelin' jealous or overlooked or what?
Nope. It's what people do when advocating for an open source project.
Before disregarding my post, the O2 DLLC debug console works well with GUI centric code.
-
PS: I seldom listen to my own mutterings :)
Hehe, now tell me how you don't talk to your robotic vacuum cleaner when it stumbles upon your feet or how you don't talk to your television in the middle of a soccer or baseball match! :P
-
I remember giving up my black&white telly around 1987 - It babbled too much, and never listened to what I had to say. It was eventually used as a monitor for an EPROM programming device.
re: printf
I tried late binding msvcrt after the console was initialised. But that did not work, so I tried : _cprintf, and that worked (direct console output). So the problem appears to be a disconnection with STDOUT.
http://msdn.microsoft.com/en-us/library/7ax4dbdt.aspx
http://msdn.microsoft.com/en-us/library/7x2hy4cx.aspx
Thanks for your detailed description of FBSL operations, Mike.
-
Ta-da-a-a-a-a!!! :D
Charles,
I've found a way to bind any console to the msvcrt's internal file buffers (including stdin, stdout, and stderr). Such functions as fprintf() with an explicit reference to a file buffer can even utilize an external user-defined FILE structure for its file buffer.
printf() is however bound to the msvcrt's internal file array element preset as stdout so its initialization is just a couple of lines longer.
I'm currently running tests but in the meantime you can enjoy
fprintf @stdout, "%s and his %s%d%s", "Charles", "O", 2, cr
fprintf'ed via a user-defined stdout structure in Oxygen's standard Console.inc's console as it runs in gxo2:
.
-
Very good Mike,
Can you pls show me your code, setting up for fprintf stdout.
Must sleep now. Happy hunting!
-
Sure Charles,
Have a good rest. The test script will be waiting for you below -- both runnable in gxo2 and compilable into a console exe:
#console
includepath "$\inc\"
'$filename "fprintf.exe"
'include "rtl32.inc"
include "Console.inc"
indexbase 0
' _iob[FOPEN_MAX] is msvcrt's internal file buffer array.
' _iob[] can be exported directly, or via cdecl __p__iob(), or via cdecl __iob_func().
' Reference:
' #define FOPEN_MAX 20
' #define STDIN_FILENO 0
' #define STDOUT_FILENO 1
' #define STDERR_FILENO 2
' #define stdin &_iob[STDIN_FILENO]
' #define stdout &_iob[STDOUT_FILENO]
' #define stderr &_iob[STDERR_FILENO]
type FILE
char* _ptr
int _cnt
char* _base
int _flag
int _file
int _charbuf
int _bufsiz
char* _tmpfname
end type
! __p__iob cdecl lib "msvcrt.dll" () as sys
! _open_osfhandle cdecl lib "msvcrt.dll" (sys a, b) as sys
! _fdopen cdecl lib "msvcrt.dll" (sys a, char* b) as sys
! setvbuf cdecl lib "msvcrt.dll" (sys a, char* b, sys c, d)
! fprintf cdecl lib "msvcrt.dll" (sys a, char* b, ...)
! printf lib "msvcrt.dll" (char* a, ...)
! memcpy lib "msvcrt.dll" (sys a, b, c)
#define _O_TEXT 0x4000 // CRLF in file becomes LF in memory!
#define _IONBF 0x4
' same for ConsIn/"r", ConsErr/"w"
sys hCrt = _open_osfhandle(ConsOut, _O_TEXT)
sys hf = _fdopen(hCrt, "w")
' user-defined buffer (for fprintf() only!)
FILE mystdout at hf
setvbuf @mystdout, NULL, _IONBF, 0
' _iob's internals:
' stdin at _iob as "r",
' stdout at iob+sizeof(FILE) as "w"
' stderr at _iob+2*sizeof(FILE) as "w"
sys _iob = __p__iob()
memcpy _iob + sizeof(FILE), hf, sizeof(FILE)
setvbuf _iob + sizeof(FILE), NULL, _IONBF, 0
fprintf @mystdout, "fprintf via mystdout: %s and his %s%d%s", "Charles", "O", 2, cr
fprintf _iob + sizeof(FILE), "fprintf via stdout : %s and his %s%d%s", "Charles", "O", 2, cr
printf "printf via stdout : %s and his %s%d%s", "Charles", "O", 2, cr
waitkey
.
-
Hi Mike,
Many thanks! That is seriously technical, and very useful to get some insight into MSVCRT. I have been playing with it :)
PS:
How to tell whether a function is cdecl or not:
espval=esp
memcpy _iob + sizeof(FILE), hf, sizeof(FILE)
print espval-esp cr 'This will be 12 if the function has not been declared cdecl
Lib declaration block
extern cdecl lib "msvcrt.dll"
! __p__iob () as sys
! _open_osfhandle (sys a, b) as sys
! _fdopen (sys a, char* b) as sys
! setvbuf (sys a, char* b, sys c, d)
! fprintf (sys a, char* b, ...)
! printf (char* a, ...)
! memcpy (sys a, b, c)
end extern
-
Hi Charles,
Thanks for fixing my declarations. Of course all the functions in msvcrt are cdecl by definition. The slip of my pen was due to FBSL always fixing the stack pointer transparently so that it makes no difference whatsoever to the user if the function to be called from an external library is in fact stdcall or cdecl. There are a couple dozens such C finctions that I don't need to look up the definitions for, and memcpy() and printf() happen to be among them.
I gather O2 must be doing the same trick or the script would have crashed at the first misdeclared cdecl call encountered? ;)
P.S. Console.inc included and functions declared as above, a somewhat prettified procedure of stdout initialization might look like this:
#define _IONBF &H4
#define _O_TEXT &H4000
#define STDOUT_FILENO 1
#define stdout @_iob[STDOUT_FILENO]
sys hCrt = _open_osfhandle(ConsOut, _O_TEXT)
sys hf = _fdopen(hCrt, "w")
FILE* _iob = @(__p__iob())
memcpy stdout, hf, sizeof(FILE)
setvbuf stdout, NULL, _IONBF, 0
fprintf stdout, "fprintf via stdout : %s and his %s%d%s", "Charles", "O", 2, cr
(Coloration is like in Oxygen's SciTE -- not very much to my liking BTW)
-
So my question is, how would you mutter to yourselves hWnd when typing a function call?
H Wind
wind as in a breeze, not wind as in winding a watch
-
Hi Mike,
Re: Scite Ide Colors
Not my favorite either. You are welcome to improve them if you have a favorite colour scheme. You will find ThemeStandard, ThemeDark, and ThemeLight.PROPERTIES in ide/. The themes are selected at the end of Oxygen.PROPERTIES.
Here is ThemeStandard.PROPERTIES
# Light Theme by kryton9
# OxygenBasic Styles
style.vb.32=fore:000000,back:EEEEEE,font:Courier New,size:12
# Symbols
style.vb.0=fore:000000,back:EEEEEE,font:Courier New,size:12
# Comment
style.vb.1=fore:224400,back:EEEEEE,font:Courier New,size:12
# Number
style.vb.2=fore:880000,back:EEEEEE,font:Courier New,size:12,bold
# Keyword
style.vb.3=fore:1100AA,back:EEEEEE,font:Courier New,size:12,bold
# String
style.vb.4=fore:2200AA,back:EEEEEE,font:Courier New,size:12,bold
# keywords 2 Directives Preprocessor
style.vb.5=fore:440000,back:EEEEEE,font:Courier New,size:12
# Operator
style.vb.6=fore:000000,back:EEEEEE,font:Courier New,size:12
# Identifier
style.vb.7=fore:000000,back:EEEEEE,font:Courier New,size:12
# Date
# style.vb.8=
# End of line where string is not closed
# style.vb.9=
# keywords3
#style.vb.11=fore:222222,back:EEEEEE,font:Courier New,size:12
# keywords4
#style.vb.12=fore:222222,back:EEEEEE,font:Courier New,size:12
# Constant
style.vb.13=fore:222222,back:EEEEEE,font:Courier New,size:12
# Asm
# style.vb.14=
# Label
style.vb.15=
# Error
style.vb.16=
# HexNumber
style.vb.17=
# BinNumber
style.vb.18=
# Line number
style.vb.33=fore:333333,back:#DDDDDD,font:Courier New,size:12
# Indentation guides
style.vb.37=fore:#CCCCCC,back:#CCCCCC
if style.vb
caret.fore=#000000
selection.alpha=128
selection.back=#CCCCCC
if style.vb
fold.margin.colour=#555555
fold.margin.highlight.colour=#555555
fold.symbols=0
#the below only work for fold.symbols >= 2
#fold.highlight=1
#fold.highlight.colour=#007700
-
Charles,
I think Mike was referring to the O2 forum. I have syntax highlighting working on the SB forum and sent you a message some time ago offering to install it here. Your call.
John
-
Thanks John.
I could not decide whether to use it. I am a minimalist at heart.
Mike,
I have fixed the pointered typedef problem. So you should be able to create variables with pointer, as well as cell*
Pointered Typedefs example
typedef struct _tt
==================
{
sys a,b,c
} tt,*pt
function f(pt b)
================
pt a at getmemory 120
a.b=42
print a.b '42
print b.b '2
freememory @a
end function
Test
====
tt a={1,2,3}
f a
http://www.oxygenbasic.org/o2zips/Oxygen.zip
PS: One can often get away with undetected cdecl calls within an O2 function because the epilog restores the stack pointer from the ebp register. Such calls inside a loop, risk a stack overflow, however.
-
Hi guys,
@Kuron:
That's it! :D
Following the lofty "hwat", "hwen", "hwere" as an intuitive template, I've been always muttering it as "hwind". But I was also always too shy to ask whether I'd make a laughing stock of myself if ever caught at doing that by somebody who really knows how it should sound. One item off the long list of questions that must be resolved before I go. :)
@John:
Yes, I think it would add elegance to the overall look of the site. Of course if Charles' Spartan style and Stoic philosophy permit. :) (Regretfully, I can't do the same at FBSL because the phpbb3 board simply doesn't support this feature.)
@Charles:
1. Thanks much for syntax highlighting directions and Kryton's theme as a template. I'll try to readjust my SciTE environment to my liking so that it wouldn't distract my attention any more.
2. char*/pointer usablity is good news. It does add to Oxygen's consistency regardless of someone's paranoia about the code it's going to be used in. ;)
3. Thanks also for making me aware of stack issues with misdeclared cdecl functions in a loop.
-
I've been always muttering it as "hwind".
Great minds think alike. ;)
I was also always too shy to ask whether I'd make a laughing stock of myself if ever caught at doing that by somebody who really knows how it should sound. One item off the long list of questions that must be resolved before I go. :)
The real fights only happen over how to pronounce GIF, JPG or PNG. ;c)
-
In fact, GIF poses no problems. I'm calling it as is, i.e. same as in gift (or Gibson, for that matter :D ). And I'm almost 100% sure that's correct for English speakers too, of course if there's no native English speaker who would try to persuade me that Gibson should be pronounced as Jibson. (see also below)
PNG is also easy to me. Matter is, Russian speakers tend to pronounce abbreviations as they would sound in Russian transliteration. For example, the English (hehehe) KGB sounds as ke-ge-`be here, where e is like in English bet and g is like in gift. By the same token, PNG is pe-en-`ge to me. I think it resolves to ping or something similar to English speakers, doesn't it?
JPG is more complicated because there are no equivalents to your J (jey) or G (jee) sounds in either Russian or German that Russians took many technical terms from. So everyone tends to pronounce it as d-zh-`peg here, wherein d is the same as English d and zh is like French j but not as much palatalized. But I'm somewhat unsure how English speakers would tend to resolve this abbreviation. Yet I think this would be the case where jey-pee-jee would fit in perfectly, wouldn't it?
-
In fact, GIF poses no problems. I'm calling it as is, i.e. same as in gift (or Gibson, for that matter :D ). And I'm almost 100% sure that's correct for English speakers too, of course if there's no native English speaker who would try to persuade me that Gibson should be pronounced as Jibson. (see also below)
The "GI" in GIF is pronounced like the "GI" in giraffe. Which makes it sound exactly like the peanut butter brand, Jif. "G" words often have a "Ja" (the "a" being short not long) sound to the "G".
PNG is also easy to me. Matter is, Russian speakers tend to pronounce abbreviations as they would sound in Russian transliteration. For example, the English (hehehe) KGB sounds as ke-ge-`be here, where e is like in English bet and g is like in gift. By the same token, PNG is pe-en-`ge to me. I think it resolves to ping or something similar to English speakers, doesn't it?
Ping is the correct pronunciation. However, I generally pronounce it as you suggest.
JPG is more complicated because there are no equivalents to your J (jey) or G (jee) sounds in either Russian or German that Russians took many technical terms from. So everyone tends to pronounce it as d-zh-`peg here, wherein d is the same as English d and zh is like French j but not as much palatalized. But I'm somewhat unsure how English speakers would tend to resolve this abbreviation. Yet I think this would be the case where jey-pee-jee would fit in perfectly, wouldn't it?
The correct pronunciation is "Jay-Peg". However, I generally pronounce it as you suggest.
-
JayPeg - Stallion
(http://www.freemanstallions.co.za/graphics/stallions/jay-peg/jay_peg0.jpg)
-
The Urban Dictionary also says that JPEG may constitute a part of a girl's name.
Cf. My girlfriend's name ends in .jpeg.