Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - Astrobe

Pages1
#1
Anything else we might add? / Newlisp vs Lua
September 12, 2017, 12:41:31 AM
Let's Rock'n'Troll!



I've lurked on comp.lang.forth for a long time. One thing I couldn't understand is why people constantly compared Forth with C, which was pointless in my eyes because they where in whole different categories.

It became even more pointless when Lua began to gain traction, because as a lightweight interpreted language, it was a serious contender. That's even more true for Newlisp.



+ Lua and Newlisp are about the same binary size, but Newlisp packs a lot more functionality out of the box

+ Newlisp doesn't rely on garbage collection (but the pass-by-value semantics that ORO requires are sometimes difficult to deal with)

+ Newlisp has macros

+ Newlisp's documentation is better

+ Newlisp is a simpler language, so I believe that parsing speed is better than Lua.

- Lua is faster, even without JIT

- Lua has better debugging support

- Lua has coroutines (Newlisp has IPC but it's heavier and not 100% multi-platform)

- Lua has much more mind share (nothing you can do about it, except make Newlisp better)



All points are not equally important. Lacking lightweight threads isn't a big deal as long as one has non-blocking I/O. Debugging support is important because bug squashing can kill productivity - especially for late-bound dynamic languages in which a simple typo can result in a bug (that's why most such languages have a so-called "strict mode"). Being slow can be acceptable to some extend, as long as interfacing with C (or eventually with external programs but that's really a last resort) is easy.
#2
newLISP in the real world / IUP bindings
September 24, 2014, 01:02:09 AM
Hello,



Doe anyone have bindings for the IUP library?
#3
newLISP in the real world / Optimisations
March 21, 2014, 02:22:00 AM
Arrays versus Lists



The deal is that lists are good at insertion and bad at random access, while arrays suck at insertion and are good at random access (I've measured a 30% difference on random accesses).

More often than not, one does a bit of both, so the choice between lists and arrays is not obvious; and it can evolve as the application evolves. However there is one case where the choice is simple: data structures, and objects. It seems to me that objects should be implemented as arrays rather than lists, because one typically perform random accesses to properties or fields of objects, and it seems unlikely that one needs to add/remove a field.



Micro-optimisations



I've read that on current processors, one thing that matters as far as performance goes, are conditionnal jumps.

I have replaced the "if ladder" on lines 1547 and following with the switch() in function evaluateExpression(), and moved the second if statement (cell->type is symbol or context) in the switch statement below. I observed a gain of performance between 7% and 10%.



However this kind of micro-optimisation is very volatile and depends a lot on the compiler, the processor, and the context. If I replace the "if ladder" near line 1525 by a switch case on args-type, I observe a slight loss in performance. My "benchmark" is a broken implementation of the map operator with a for loop. I'm not sure if it's actually "good" way to measure performance. I think we need a set of standard benchmarks.
#4
newLISP in the real world / portability issue with net-receive-from
March 18, 2014, 03:43:05 AM
I used (net-receive-from) to make a little UDP proxy under linux. When I ran it under windows, it unexpectedly didn't work.



It seems that under Windows (XP), the address field which is returned is in the form ip-address:port.
#5
newLISP in the real world / read-line optimisation
March 04, 2014, 12:42:09 AM
Hello,



While programming a little tool that analyses some log file, I've noticed that read-line is a bit slower than one would expect. Looking at its code, it appeared to me reading the stream char-by-char could be the cause. I Modified it to use fgets instead:


Code Select

char * readStreamLine(STREAM * stream, FILE * inStream)
{
char buf[MAX_STRING];
size_t l;

openStrStream(stream, MAX_STRING, 1);

if(fgets(buf, MAX_STRING, inStream)!=NULL)
{
l=strlen(buf);
if(buf[l-1]==0x0A)
        {
             buf[--l]=0;
             if(buf[l-1]==0x0D) buf[--l]=0;
        }
writeStreamStr(stream, buf, l);
return(stream->buffer);
}
else
{
if(feof(inStream)) clearerr(inStream);
return NULL;
}
}


(this hasn't been heavily tested)



However, it doesn't strictly respects the original semantics of read-line with regards to newline characters. To be honest, I don't understand why they are that way, in particular why there is a requirement that a newline at the end of the file has to be erased.



Also, the part about the TRU64 is missing. I don't know if fgets handles EINTR correctly by itself on this platform. I've worked with systems plagued with a similar illness before, and unfortunately the FILE library (which was not standard IIRC) didn't handle very it well.



On the performance side, timings drop from 250ms to 50ms.
#6
Whither newLISP? / fexpr issues
February 28, 2014, 01:42:33 AM
Consider this dumbed-down version of do-until:


Code Select

(module "macro.lsp")
(define-macro (DO-UNTIL test B)
 (do-while (not (eval test)) (eval B)))

(macro (DO-UNTIL* T B)
(do-while (not T) B))


(println "test 1")
(define (foo k)
  (DO-UNTIL (<= k 0) (begin (println k) (dec k))))
(foo 3)

(println "test 2")
(define (foo* k)
(DO-UNTIL* (<= k 0) (begin (println k) (dec k))))
(foo* 3)

(println "test 3")
(define (bar*)
  (let (k 0)
(DO-UNTIL* (>= k (args 0)) (begin (println k) (inc k)))))
(bar* 3)

(println "test 4")
(define (bar)
  (let (k 0)
(DO-UNTIL (>= k (args 0)) (begin (println k) (inc k)))))
(bar 3)


First problem: foo doesn't behave correctly under debug; doing (debug (foo 3)) doesn't do the same as (foo 3)



Second problem: bar doesn't work at all, because (args 0) is evaluated in the context fo the macro DO-UNTIL.



Those kind of problems makes it really tricky to use fexprs. On the other hand, rewrite macros provided by macro.lsp don't have these problems, and are also faster because the substitution is done at compile-time. They however increase the code size, but this can be mitigated by factoring out the "big parts" of macros in external functions.



macro.lsp notes that it increases the load-time of scripts. Is the impact significant? What about native and improved support for rewrite macros?
#7
newLISP in the real world / FFI - struct passed by value
January 28, 2014, 02:46:54 PM
I'd like to use this nice little GUI library: http://enchantia.com/software/graphapp/">http://enchantia.com/software/graphapp/



The widget set is not as full featured as other libraries but it's good enough for simple user interfaces. Plus it fits in a single 700K DLL and is portable.



The problem is that it passes and returns one of its major structures (Rect) as value: http://enchantia.com/software/graphapp/doc/manual/rect.htm">http://enchantia.com/software/graphapp/ ... l/rect.htm">http://enchantia.com/software/graphapp/doc/manual/rect.htm



Is there, by any chance, some trick to make it work with NewLisp's FFI without writing wrappers?
#8
Whither newLISP? / registering C functions to Newlisp
January 15, 2013, 02:19:59 PM
I'd like to use Newlisp on system that runs uClinux, which does not support shared libraries. I also would like to use some C++ libraries.



My first idea was to hack a bit Newlisp so that one could relatively easily add "foreign" functions to the list of primitives functions. But another difficulty is to link C and C++ together. The best way is to compile the C files (newlisp) with C++ (my libraries), but compiling newlisp as C++ fails (it might be possible, but I also have to use a quite old version of gcc).



Another idea is to use the newlisp-as-library way: compile a small main() and my libraries with G++, then link the newlisp static library to it. The extra step to make it work is to be able to register, with a C function provided by the newlisp library, another C function (which would in my case just be an interface for calling C++ stuff). I took a look at nl-import.c and the code that imports C functions from shared libraries and it seems to me it's possible to do that.



I'm not yet familiar with newlisp's internal and I'd like to hear your opinion on how easy or hard it would be to do that before diving in.
Pages1