|
Post by barryk on Mar 1, 2014 10:59:08 GMT 1
Hi, I am using 2.5.0beta, downloaded a couple of weeks ago.
A variable defined at BaCon level used in a USEC block, used to compile ok, but not now:
thisfile$="/tmp/pup_event_ipc/popup_msg" USEC #define O_RDONLY 00000000 #define O_RDWR 00000002 //thisdescr=open(thisfile$,O_RDWR); thisdescr=open("/tmp/pup_event_ipc/popup_msg",O_RDWR); END USEC
There is a compile error, reports that "thisfile$" is undefined. I commented out that line, replaced with the actual string, and it compiled.
Note also, executing "bacon -d /tmp test.bac" creates the binary executable "test" in /tmp, not in the working directory.
Regards, Barry Kauler
|
|
|
Post by alexfish on Mar 1, 2014 11:46:14 GMT 1
Hi Barry tested some some bits . using a early beta version , I was getting err on the O_RDONLY = redefined symbol so had to rename 'O' to OPEN but got this bit of code to compile. ''@ here a work around by using declare DECLARE thisfile TYPE char* thisfile="/tmp/pup_event_ipc/popup_msg" '------------------------------------------------------------ '@ used Local to make bacon aware of the handle as in 'thisdescr' LOCAL thisdescr '------------------------------------------------------------ USEC #define OPEN_RDONLY 00000000 #define OPEN_RDWR 00000002 //thisdescr=open(thisfile,OPEN_RDWR); thisdescr=open(thisfile,OPEN_RDWR); END USEC '@ downside of char* is the BaCon PRINT , but can do LOCAL prt$="" PRINT prt$=thisfile
Not sure if this is correct , I did try declaring as STRING but this failed , hope Peter can confirm. there is some mention of the type of declare type Statements Here BR Alex
|
|
|
Post by bigbass on Mar 1, 2014 15:16:32 GMT 1
Hello barryk
Maybe this ? it compiles and works on BaCon without USEC
Joe
PROTO printf PROTO fopen PROTO fprintf PROTO fclose
thisfile$="/tmp/pup_event_ipc/popup_msg.txt"
DECLARE fp TYPE FILE*
fp=fopen("/tmp/pup_event_ipc/popup_msg.txt","w") fprintf (fp, "Some event message \n") fclose (fp)
|
|
|
Post by bigbass on Mar 1, 2014 16:05:22 GMT 1
Alex posted closer to what you want if you "have to" use open since ,O_RDWR is already defined by the headers we don't need to redeclare it we can remove the #define let's forget USEC too using PROTO to get the function imported
PROTO open
''@ here a work around by using declare DECLARE thisfile TYPE char* thisfile="/tmp/pup_event_ipc/popup_msg" '------------------------------------------------------------ '@ used Local to make bacon aware of the handle as in 'thisdescr' LOCAL thisdescr
'------------------------------------------------------------
thisdescr=open(thisfile,O_RDWR)
|
|
|
Post by Pjot on Mar 1, 2014 18:37:18 GMT 1
Well, I do not believe this worked before; it does not compile with BaCon 2.4, nor with 2.3. Actually, I wonder if it ever compiled, and the reason is that the variable 'thisfile$' is passed as-is to the C source, because of the USEC statement; however, when used in BaCon code, the ending '$' sign is converted to a plain text string, so other C compilers accept such a variable name (the ISO C standard does not allow the '$' to be part of a variable name). So in reality, the variable 'thisfile$' is converted to 'thisfile__b2c__string_var' and that variable is declared in the header file. This conversion from the '$'-suffix to a plain variable name has been in BaCon since version 1.0 build 11. Anyway, if you want to open a file, you can simply use the OPEN ... FOR WRITING/READING/APPENDING/READWRITE statements also. If you really need to specify the open mode, then you can define the open mode with OPTION DEVICE and then use OPEN .. FOR DEVICE. HTH, Peter
|
|
|
Post by barryk on Mar 2, 2014 9:24:54 GMT 1
Peter, Hi, it did compile. Back in June 2013, I was compiling the attached program, many times. It has that exact same code with "thisfile$". The program also worked (and I have the binary to prove it!). But, it no longer compiles. Note, back then, those constants such as "O_RDWR" were not defined, which is why I had them defined in the program. Regards, Barry Kauler P.S. 01slacko in the Puppy Forum did mention something about this recently, that he had to go back to an earlier version of BaCon to compile this program. He was recompiling it for his x86-64 version of Puppy. Attachments:pup_event_ipc.bac.gz (2.64 KB)
|
|
|
Post by barryk on Mar 2, 2014 9:42:21 GMT 1
Ok, I have located the directory on my hard drive where I was compiling pup_event_ipc.bac back in June 2013. It also has the 'bacon' executable that I was using then -- and it is version 2.1.7.
Regarding the high-level OPEN, etc., I used the low-level C functions for a reason, but I don't recall what exactly. There was something that the high-level BaCon OPEN (etc) did not do as I wanted. I know that, because I recall using them at first, then was forced to go down to the low-level C functions -- wish that I could recall what it was exactly.
Trying to recall, it may have been the file descriptor? Different with OPEN? uses a "stream" descriptor? If you run your more experienced eye down my pup_event_ipc.bac, you might pick up why I had to use the C functions.
Regards, Barry Kauler
|
|
|
Post by Pjot on Mar 2, 2014 17:20:23 GMT 1
Hi Barry, Well, you are right - I was able to compile your program using BaCon 2.1.9. But it compiles because of a bug in BaCon. There are two things going on. (1) previously, all code within USEC/ENDUSEC pairs would go through the BaCon tokenizer. That means, that variable names would be 'baconized' (but the C code would not go through the BaCon parser of course). However, when you pass embedded ASM code within the USEC/ENDUSEC pairs, this would get spoiled. The tokenizer will mess up indentation and the use of semicolons, and the ASM code would become unusable. Therefore, as of BaCon 2.2, all code within USEC/ENDUSEC will not go through the tokenizer anymore. This explains the problems you're seeing with the variables "thisfile$" and "otherfile$". These variables are not passed on to the tokenizer, which, among other things, replaces the '$' suffix into a plain string. Therefore, when the variables occur in BaCon code, they are 'baconized' into something else, something acceptable by all C compilers, but the C code is passed unmodified as-is, so without the replacement of the '$' suffix. (2) as of BaCon 2.3, the 'fcntl.h' C header is default part of BaCon, just because of the OPEN DEVICE statement. This allows a generic 'open' of anything, be it a file or a serial port or something else. The OPEN DEVICE statement can define the exact open options for you. That is also the reason why you needed that USEC in the first place, because previously, BaCon did not have the capabilities to 'open' something in a specific way. So, first of all, we can delete all "#define" stuff from your code. Secondly, we can delete all USEC/ENDUSEC also, as we are now able to redefine all 'open' methods in native BaCon statements. So, instead of this: USEC otherdescr=open(otherfile$, O_WRONLY | O_CREAT | O_APPEND); END USEC
...we can now say this: OPTION DEVICE O_WRONLY|O_CREAT|O_APPEND OPEN otherfile$ FOR DEVICE AS otherdescr
I have attached the modified program to this thread, hope it helps! BR, Peter Attachments:pup_event_ipc.bac (6.87 KB)
|
|
|
Post by barryk on Mar 3, 2014 11:23:04 GMT 1
Thanks for modifying the script! It is good to see BaCon continue to make significant improvements.
I tried to compile it the way I used to, using a method given to me by vovchik:
# bacon -o -s -o -Os -o -fdata-sections -o -ffunction-sections -o -Wl,--gc-sections -d /tmp -a pup_event_ipc.bac Converting 'pup_event_ipc.bac'... done. New BaCon archive required! Creating... Compiling 'pup_event_ipc.bac'... cc -s -Os -fdata-sections -ffunction-sections -Wl,--gc-sections -c pup_event_ipc.bac.c -lm -ldl Compiler error:
Problem: file '/usr/include/i386-linux-gnu/bits/fcntl2.h' line 50: __open_missing_mode (); Cause: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments
Then I tried this:
# bacon -d /tmp -a pup_event_ipc.bac WARNING: 8 temporary files found! Do you want to delete them (y/n)? y Temporary files were deleted. Converting 'pup_event_ipc.bac'... done. New BaCon archive required! Creating... Compiling 'pup_event_ipc.bac'... cc -c pup_event_ipc.bac.c -lm -ldl cc -c bacon.malloc.c cc -c bacon.sort.c cc -c bacon.remove.c cc -c bacon.curdir.c cc -c bacon.reverse.c cc -c bacon.str.c cc -c bacon.concat.c cc -c bacon.left.c cc -c bacon.right.c cc -c bacon.mid.c cc -c bacon.instr.c cc -c bacon.instrrev.c cc -c bacon.spc.c cc -c bacon.tab.c cc -c bacon.fill.c cc -c bacon.count.c cc -c bacon.chop.c cc -c bacon.extract.c cc -c bacon.replace.c cc -c bacon.getenviron.c cc -c bacon.ucase.c cc -c bacon.lcase.c cc -c bacon.hex.c cc -c bacon.dec.c cc -c bacon.chr.c cc -c bacon.fileexists.c cc -c bacon.filelen.c cc -c bacon.filetime.c cc -c bacon.filetype.c cc -c bacon.search.c cc -c bacon.exec.c cc -c bacon.getkey.c cc -c bacon.getxy.c cc -c bacon.screen.c cc -c bacon.time.c cc -c bacon.datename.c cc -c bacon.epoch.c cc -c bacon.timer.c cc -c bacon.os.c cc -c bacon.memcheck.c cc -c bacon.memory.c cc -c bacon.peek.c cc -c bacon.wait.c cc -c bacon.host.c cc -c bacon.getpeer.c cc -c bacon.regex.c cc -c bacon.makedir.c cc -c bacon.error.c cc -c bacon.version.c ar -r bacon.a bacon.malloc.o bacon.sort.o bacon.remove.o bacon.curdir.o bacon.reverse.o bacon.str.o bacon.concat.o bacon.left.o bacon.right.o bacon.mid.o bacon.instr.o bacon.instrrev.o bacon.spc.o bacon.tab.o bacon.fill.o bacon.count.o bacon.chop.o bacon.extract.o bacon.replace.o bacon.getenviron.o bacon.ucase.o bacon.lcase.o bacon.hex.o bacon.dec.o bacon.chr.o bacon.fileexists.o bacon.filelen.o bacon.filetime.o bacon.filetype.o bacon.search.o bacon.exec.o bacon.getkey.o bacon.getxy.o bacon.screen.o bacon.time.o bacon.datename.o bacon.epoch.o bacon.timer.o bacon.os.o bacon.memcheck.o bacon.memory.o bacon.peek.o bacon.wait.o bacon.host.o bacon.getpeer.o bacon.regex.o bacon.makedir.o bacon.error.o bacon.version.o >/dev/null 2>&1 Compiler error:
make: Warning: File `pup_event_ipc' has modification time 2.8e+04 s in the future make: warning: Clock skew detected. Your build may be incomplete.
...and I did not get a 'pup_event_ipc' executable.
The bacon that I am using was downloaded on 7 Feb. and identifies itself as "2.5.1 beta".
Regards, Barry Kauler
|
|
|
Post by barryk on Mar 3, 2014 11:37:08 GMT 1
There must be a conflict between the files created in /tmp by the first attempted compile using vovchik's method and the second attempt.
I tried it with "bacon -d /tmp/temp1 pup_event_ipc.bac" and it compiled.
That's great!
|
|
|
Post by 01micko on Jul 11, 2014 3:07:15 GMT 1
I know this is thread is getting a bit old but I had issues compiling Barry's pup_event_frontend_d.bac and Peter's modified pup_event_ipc.bac with BaCon 3.0 I managed to get it done (yes I red the doc about IF/THEN/ELSE and nesting, fixed that) but I had to use USEC for one line in pup_event_frontend_d.bac and pup_event_ipc.bac. Can someone take a look and tell me what it would take to get this done with native code or is USEC the only way? Both files attached. Thanks. Mick
|
|
|
Post by bigbass on Jul 12, 2014 9:06:58 GMT 1
Hey 01micko First check the latest beta from the bacon main page Then check this I documented some relevant stuff here that will go into more detail basic-converter.proboards.com/post/6424basic-converter.proboards.com/post/6430a post or link of the original unedited code would be better for testing if it compiles or not for us but if this attached code works and you just want to remove USEC Joe
|
|
|
Post by 01micko on Jul 12, 2014 12:18:21 GMT 1
Hey Joe! Your examples make some sense and reducing overhead looks like a good idea. I'm brand new with bacon and not much older with C I'll try to get my head around this to get the complete picture. The examples I posted both compile and work and are directly derived from Barry's work and Peter's adjustments. My main issue was that I couldn't get it to build without USEC but your examples and links should show me the way.. (tomorrow when the head is a bit clearer.) Thanks Mick
|
|
|
Post by vovchik on Jul 12, 2014 13:36:30 GMT 1
Dear 01micko, Welcome to the forum. Always nice to see old friends from from the kennels. Onve you get the hang of BaCon - and it won't take you long - you will be able to create little gems of use to all of us. You can call C functions in existing libs and do a great deal with very little in terms of coding and resource utilization. If you need some advice or have a question, just bark and somebody will hear you and respond. With kind regards, vovchik
|
|
|
Post by Pjot on Jul 12, 2014 17:50:40 GMT 1
Hi 01micko, In the sourcefile 'pup_event_ipc.bac' there is just one real USEC instance: USEC int eventstatus=poll(&pfd.fd,1,milliseconds); END USEC
You can simply remove the USEC stuff here, and the preceding 'int'. So this will compile also: eventstatus=poll(&pfd.fd,1,milliseconds)
Alternatively, the C function 'poll' probably can be replaced with the BaCon function WAIT. I am not sure if this really works, but you can try the following: eventstatus = WAIT(pfd.fd,milliseconds)
In the file 'pup_event_frontend_d' I can see that the socket setup is implemented on a very low-level. The BaCon statement OPEN FOR SERVER does the same thing. In fact, it looks as if the code can be rewritten completely using OPEN FOR SERVER, WAIT and RECEIVE. Hope this gives some leads.... HTH Peter
|
|