ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: | Check also for more information
_whitelogger has joined #picolisp
jibanes has quit [Ping timeout: 268 seconds]
jibanes has joined #picolisp
orivej has joined #picolisp
sarna has joined #picolisp
<sarna> o/
rob_w has joined #picolisp
<razzy> sarna: new face?
<sarna> razzy: hm? I'm waving hi
<razzy> hi
<razzy> sarna: just curious, is sarna female slavic nick?
<sarna> razzy: well, it is a valid word in Polish, as well as in Spanish
<razzy> i am satisfied with answer. thx.
freemint has joined #picolisp
<Regenaxer> Hi sarna, razzy
<sarna> hello
<razzy> afk
razzy has quit [Ping timeout: 246 seconds]
sarna has quit [Quit: sarna]
xkapastel has joined #picolisp
f8l has quit [Ping timeout: 265 seconds]
sarna has joined #picolisp
f8l has joined #picolisp
rob_w has quit [Remote host closed the connection]
rob_w has joined #picolisp
libertas_ is now known as libertas
xkapastel has quit [Quit: Connection closed for inactivity]
beneroth has quit [Quit: Leaving]
mtsd has joined #picolisp
andyjpb has joined #picolisp
bitmapper has joined #picolisp
<tankf33der> o/
<tankf33der> if clang9 and llvm8 it failed.
<tankf33der> if clang9 but llvm8 it failed.
<Regenaxer> ok
<Regenaxer> btw, I cooked down the issue
<Regenaxer> Put this into a file named "sym.ll"
<Regenaxer> Then $ llvm-as -o sym.bc sym.ll
<Regenaxer> then $ llc sym.bc && vi sym.s
<Regenaxer> Can you send me "sym.s"?
<Regenaxer> Correct is
<Regenaxer> This is arm64, but very similar for x86
<Regenaxer> The critical line is .xword SymTab+8
<Regenaxer> this is what goes wrong
<Regenaxer> We should ask this in some LLVM forum, but I'm not sure where
<sarna> hey, does picolisp support regular expressions?
<Regenaxer> Not directly. 'match' is a very simple one perhaps
<Regenaxer> But you can call 'native'
<sarna> oh well
<Regenaxer> See RosettaCode task "Regular expressions"
<sarna> alright :)
<sarna> looks nice
<sarna> is @ something like a topic variable in Perl?
<Regenaxer> I don't know Perl
<Regenaxer> In some functions symbols starting with "@" are used as "pattern variables"
<Regenaxer> also Pilog variables
<sarna> found a lot of info here: :)
<tankf33der> Regenaxer:
<tankf33der> # llvm-as -o sym.bc sym.ll
<tankf33der> llvm-as: sym.ll:1:2: error: expected top-level entity
<tankf33der> .text
<tankf33der> ^
freemint has quit [Ping timeout: 252 seconds]
<tankf33der> i did some progress with code above
<tankf33der> with this one
<tankf33der> code you mention as not correct
<tankf33der> 32bit on left and 64bit on right side
freemint has joined #picolisp
<Regenaxer> yes, as yesterday
<Regenaxer> assembller geneates "&" with garbage following
<Regenaxer> So llvm-as is faulty it seems
<sarna> how to compare strings? = doesn't seem to work
<Regenaxer> We should present "sym.s" in some forum
<Regenaxer> I think "sym.ll" is correct
<Regenaxer> or is there a better way?
<Regenaxer> sarna: With '='
<Regenaxer> or '>=' etc.
<Regenaxer> In which sense does it not work?
<sarna> Regenaxer: oh damn, I got dyslexic out of sudden
<sarna> I was comparing angle brackets with parentheses..
<Regenaxer> :)
<Regenaxer> font too small?
<sarna> no, it's just sometimes I read something in a wrong way and it stays like this in my brain
<sarna> gets worse when I'm tired :)
<Regenaxer> What is your local time?
<sarna> 3PM
<sarna> nearing the end of my workday
<sarna> by the way, can I lint a file somehow?
<Regenaxer> yes, @lib/lint.l
<sarna> I can't figure out how to apply this to a file
<Regenaxer> Ah, yes, it links in-memory
<Regenaxer> hmm, there was a file option too ...
<Regenaxer> yes, 'lintAll'
<sarna> (lint "filename") doesn't work, (lint (in "filename" (till NIL T] doesn't work either :(
<Regenaxer> right, 'lint' goes to symbols directly
<Regenaxer> (lintAll "file1" "file2" ...)
<Regenaxer> But most sense makes lint in memory
<Regenaxer> it cross-checks definitions etc.
<sarna> well, yeah
<sarna> can code fix itself on the fly? :D
<Regenaxer> yes
<Regenaxer> manually, or with things like 'patch'
<Regenaxer> So you also have central european time
<sarna> nice :^)
<sarna> yep
<tankf33der> let me try sparc, llvm-6
<Regenaxer> hmm
<Regenaxer> I think it works nowhere
<Regenaxer> Bug in llvm-as
<tankf33der> but x64 is ok
<Regenaxer> yes, pointer and long both 64 bits
<Regenaxer> I tested on arm64 and x86-64
<tankf33der> this is sparc, llvm6
<Regenaxer> The above code stores a pointer in a 64 bit array
<Regenaxer> thats the problem
<Regenaxer> yes, .xword SymTab+8 is good
<Regenaxer> but that is x86-64, right?
<tankf33der> 16:32 <tankf33der> this is sparc, llvm6
<Regenaxer> 32 bits?
bitmapper has quit [Ping timeout: 276 seconds]
<tankf33der> 64
<Regenaxer> yeah
<Regenaxer> problem is 32
<Regenaxer> Something with the mismatch of pointer and long it size
<sarna> should global variables be named like *global-variable? I'm not sure, reading the style guide
<Regenaxer> Yes, usually *Global-...
<Regenaxer> or lower case, usually functions
<tankf33der> testing, 32bit, 3.4.2
<Regenaxer> 'cdr' is a global :)
<Regenaxer> tankf33der, thx!
<sarna> hmm, how would you name a global counter in a script that solves some programming exercise?
<Regenaxer> I wonder if it is a bug in llvm, or if an option fixes it
<Regenaxer> I would call it *Cnt or *Count
<tankf33der> # llvm-as -o sym.bc sym.ll
<tankf33der> llvm-as: sym.ll:3:26: error: expected value token
<tankf33der> ^
<tankf33der> i8* getelementptr (i8, i8* bitcast ([4 x i64]* @SymTab to i8*), i32 8)
<sarna> why uppercase? because it's not a function?
<Regenaxer> Case does not matter here, *cnt is ok too
<sarna> ah, okay. just wondering what's the convention :)
<Regenaxer> 'lint' just checks the "*"
<Regenaxer> tankf33der, strange
<Regenaxer> the whole entry is
<Regenaxer> i64 ptrtoint (
<Regenaxer> i8* getelementptr (i8, i8* bitcast ([4 x i64
<Regenaxer> to i64 ),
<Regenaxer> the 64 bit array entry
<tankf33der> i will go to official llvm channel
<Regenaxer> ok, me too
<Regenaxer> on
<tankf33der> afk.
<Regenaxer> The problem is not easy to explain
<tankf33der> maybe open issue in llvm’s bugzillla?
<Regenaxer> not sure
<tankf33der> i can open issue then
<tankf33der> easy steps how to repeat
<Regenaxer> ok, great!
<tankf33der> afk
<Regenaxer> The thema is "insert a pointer into an array of 64 bit numbers"
<Regenaxer> c.u. :)
mtsd has quit [Quit: Leaving]
freemint has quit [Ping timeout: 245 seconds]
rob_w has quit [Quit: Leaving]
freemint has joined #picolisp
<tankf33der> 72 bugs in last 7 days
<tankf33der> i dont understand how this thing works.
<Regenaxer> Wow
<Regenaxer> and "New user self-registration is disabled"
<Regenaxer> are you registered already?
<tankf33der> no
<tankf33der> i've requested useradd by email.
<Regenaxer> ah
<tankf33der> bugzilla is not for humans too.
<Regenaxer> indeed, I did not like it last time (15 years ago)
<Regenaxer> Hmm, I wonder if the problem is only in SymTab or also in function code
<Regenaxer> This returns NIL from the Symbab from function 'foo'
<Regenaxer> Could you llvm-as -o sym.bc sym.ll agaain?
<tankf33der> not now
<Regenaxer> ok, no hurry
<tankf33der> but today.
<Regenaxer> :)
<Regenaxer> llvm is crazy
<Regenaxer> a simple "ret Nil" is expressed as:
<Regenaxer> ret i64 ptrtoint (i8* getelementptr (i8, i8* bitcast ([4 x i64]* @SymTab to i8*), i32 8) to i64)
<Regenaxer> horror
<Regenaxer> So maybe this expression gives the same problem as statically in SymTab
<tankf33der> Regenaxer: you could connect to #llvm on ofct
<tankf33der> i gonna push
<Regenaxer> I am connected
<Regenaxer> did not watch :)
freemint has quit [Ping timeout: 276 seconds]
<Regenaxer> tankf33der: Seems our question is already forgotten
<tankf33der> as is.
<tankf33der> not a problem to open issue.
<tankf33der> :)
<Regenaxer> yeah
<tankf33der> or write to ML
<Regenaxer> I think the subject should be
<tankf33der> i can post to reddit as warmup
<Regenaxer> "i64 ptrtoint (<pointer>) to i64" on 32-bit
<Regenaxer> this is the core of the problem
<Regenaxer> converting a pointer to i64
<Regenaxer> on 32 bit
<tankf33der> i will do it
<Regenaxer> post there?
<Regenaxer> Whatever is easier :)
<tankf33der> both.
<Regenaxer> good
<Regenaxer> parens were wrong. Correct is:
<Regenaxer> "i64 ptrtoint (<pointer> to i64)" on 32-bit
<Regenaxer> Perfect!
<Regenaxer> Short question but to the point :)
<tankf33der> my english is weak.
<Regenaxer> No, looks good
<Regenaxer> perfect, as I said :)
<Regenaxer> Answers will appear under the same link?
<tankf33der> yea, in comment.
<Regenaxer> ok
<tankf33der> what ML I should use ?
<tankf33der> list is big.
<Regenaxer> indeed
<Regenaxer> llvm-dev ?
<Regenaxer> llvm-bugs is too early
<Regenaxer> not a bug but my error probably
<Regenaxer> tankf33der, interesting:
<Regenaxer> : (hex 4294967295)
<Regenaxer> -> "FFFFFFFF"
<Regenaxer> So llvm-as padded the pointer's upper 32 bits with 1s
<tankf33der> also mentined
<Regenaxer> ok
<Regenaxer> 1s are ok for me
<Regenaxer> problem is that it generates illegal assembly code
<Regenaxer> The pointer is used only in the lower 32 bits on a 32-bit machine, so *which* padding does not matter
<Regenaxer> The "&" seems illegal syntax
<Regenaxer> Let's ssee :)
freemint has joined #picolisp
sarna has quit [Quit: bye]
sarna has joined #picolisp
orivej has quit [Ping timeout: 268 seconds]
Seteeri has joined #picolisp
sarna has quit [Read error: Connection reset by peer]