ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Check also http://www.picolisp.com for more information
pointfree has quit [*.net *.split]
orivej has quit [Ping timeout: 265 seconds]
pointfree has joined #picolisp
pointfree has quit [*.net *.split]
pointfree has joined #picolisp
andyjpb has quit [Ping timeout: 245 seconds]
freeemint has joined #picolisp
freeemint has quit [Ping timeout: 276 seconds]
pointfree has quit [*.net *.split]
pointfree has joined #picolisp
karswell has joined #picolisp
pointfree has quit [*.net *.split]
pointfree has joined #picolisp
freeemint has joined #picolisp
freeemint has quit [Ping timeout: 245 seconds]
freeemint has joined #picolisp
freeemint has quit [Ping timeout: 245 seconds]
pointfree has quit [*.net *.split]
pointfree has joined #picolisp
freeemint has joined #picolisp
freeemint has quit [Ping timeout: 250 seconds]
_whitelogger has joined #picolisp
<tankf33der> Regenaxer: will try compile 32bit new code soon
rob_w has joined #picolisp
<Regenaxer> Hi tankf33der! OK, thx
<Regenaxer> I can't find a better syntax
andyjpb has joined #picolisp
<tankf33der> lets see
<Regenaxer> I'm near to giving up pil21/32
<Regenaxer> Not worth the trouble
<Regenaxer> No errors?
<Regenaxer> The generated code seems the same as on 64 bit, so this is OK
orivej has joined #picolisp
<Regenaxer> But I will need "%union.op, %union.op, %union.op ..." for *every* entry in SymTab
<Regenaxer> with as many "%union.op"s as the table has entries
<Regenaxer> Grows with the square of the table length
<Regenaxer> And SymTab has hundreds of entries
<Regenaxer> More than 400
<Regenaxer> So I must generate 1600 '%union.op's :(
<Regenaxer> And we don't know yet what other troubles we will have with differences 64 vs. 32 bit
<tankf33der> Regenaxer: i have a question about native.
<Regenaxer> ok
<tankf33der> I have to pass list to c function, c function will modify first item in it and I want get this list *back* to picolisp.
<tankf33der> never did it and stuck.
<Regenaxer> You can only destructively modify the list
<Regenaxer> ie. no 'cons', ok?
<Regenaxer> If ok, then no need to pass back the list, the pointer to the first cell is still valid
<tankf33der> oops
<Regenaxer> same :)
<tankf33der> i have this one
<tankf33der> only always 8 items.
<tankf33der> list always 8 items.
<Regenaxer> 8 Bytes
<tankf33der> yea
<Regenaxer> So not returning a list
<Regenaxer> I misunderstood
<Regenaxer> you mean byte array?
<tankf33der> yea
<Regenaxer> good
<Regenaxer> So "sodium_inc_asm" modifies it?
<tankf33der> yes, first byte
<Regenaxer> then 'Lst' has the modified bytes
<tankf33der> yeap!
<tankf33der> question: how correctly pass and return Lst
<Regenaxer> The return is as you have, but you must pass the old values
<Regenaxer> (cons Lst (cons 8 'B OldList)) ?
<tankf33der> let me
<Regenaxer> "a positive number, stored as an unsigned byte value"
<Regenaxer> So bytes are the easiest case :)
<Regenaxer> If OldList has byte values
<Regenaxer> oops, forgot a quote!
<Regenaxer> (cons 'Lst (cons 8 'B OldList))
<Regenaxer> of course
mtsd has joined #picolisp
<mtsd> Good morning!
<Regenaxer> Hi mtsd!
<mtsd> Hi Regenaxer! How are things?
<Regenaxer> Good, thanks! :)
<mtsd> Great to hear!
<mtsd> Working on llwm?
<Regenaxer> Everything ok in Sweden?
<tankf33der> it doesnt work and i dont see 'done message on screen.
<mtsd> Yes, it's ok. Winter is coming, we have a beautiful morning. Sunny and a little cold
<Regenaxer> :)
<mtsd> How is Bayern now?
<Regenaxer> cloudy
<Regenaxer> yeah, seems wrong
<Regenaxer> Perhaps (cons 'Lst (cons (8 . B) OldList)) ?
<tankf33der> i got only one item back.
<tankf33der> not array :)
<Regenaxer> looking doc native
freeemint has joined #picolisp
<Regenaxer> below "structures, passed as lists with"
<Regenaxer> hmm
<Regenaxer> (cons 'Lst (cons (8 B . 8) OldList)) ?
<Regenaxer> I forgot :)
<Regenaxer> "size and result specification in the CADR"
<Regenaxer> So size is 8
<Regenaxer> and (B . 8) means 8 byte array
<Regenaxer> So (8 . (B . 8)) which is (8 B . 8)
<tankf33der> yea, works now. thanks a lot.
<Regenaxer> :)
freeemint has quit [Ping timeout: 245 seconds]
beneroth has joined #picolisp
freeemint has joined #picolisp
freeemint has quit [Remote host closed the connection]
freeemint has joined #picolisp
<Regenaxer> Hmm, what to do? Give up pil21/32 ?
<Regenaxer> Is 32 still important?
<beneroth> Good morning
<Regenaxer> Hi beneroth!
<beneroth> is emu without pil32 possible?
<Regenaxer> emu is pil64
<beneroth> so: yes :)
<beneroth> hmm
<Regenaxer> I want to abandon pil32, pil64 and ersatz
<Regenaxer> only pil21 :)
<beneroth> uh
<beneroth> why? is pil21 so awesome?
<beneroth> is database format changing, same as in pil32 to pil64 switch?
<Regenaxer> no, same as pil64
<Regenaxer> No changes
<Regenaxer> only minor
freeemint has quit [Ping timeout: 246 seconds]
<Regenaxer> eg (arg) will not work
<beneroth> how are libraries like ht implemented in pil21, is pilASM still a thing?
<beneroth> uh
<aw-> hey beneroth!
<beneroth> hey aw- !
<Regenaxer> no pilAsm needed. All PicoLisp (kind of)
<Regenaxer> Hi aw-
<beneroth> I don't know enough about pil21 to have an opinion. is there a write-up somewhere? or all just chat history?
<Regenaxer> ht will be the same, but also in mock-Pil of course
<Regenaxer> Yeah, no write up yet :)
<Regenaxer> All too much changing
<aw-> hi Regenaxer
<Regenaxer> Reference is the source, pil21.tgz
<Regenaxer> :)
<beneroth> all I know about pil21: new pil edition, supposedly based in LLVM. no idea what this means in practical terms.
<Regenaxer> yes
<Regenaxer> The point is LLVM, I expect more portability
<Regenaxer> iOS, MacOS
<Regenaxer> The initial reason was RISC-V
<beneroth> I see
<beneroth> good spirit, though I don't know if there are even any RISC-V hardware around yet
<Regenaxer> The pil64 VM does not fit RISC-V
<Regenaxer> thats true
<Regenaxer> But LLVM is everywhere now
<beneroth> android? windows?
<Regenaxer> Android yes
<Regenaxer> Windows too, but Pil won't run
<Regenaxer> LLVM promises a lot of optimizability, but I have not investigated yet
<beneroth> ok
<Regenaxer> I make only frontend
<Regenaxer> Still I suspect it will be a *little* slower than pil64
<beneroth> I'm skeptical that those optimizations apply to pilVM, often such optimizations are for "classical" C/C++ applications..
<Regenaxer> Very true
<beneroth> Wikipedia says LLVM supports x86
<Regenaxer> But LLVM-IR is suitable for that
<Regenaxer> I mean, LLVM-IR is oriented for C etc
<Regenaxer> statically compiled langs
<Regenaxer> But then the backend is general
<Regenaxer> It has some good points, which are tedious to implement in the frontend, but once there should be very optimizable
<beneroth> I see
<Regenaxer> I see it now already by inspecting the generated machine cude
<Regenaxer> arm64 and x86-64
<beneroth> brb
<Regenaxer> I was hoping that we *could* also support 32 bit
<Regenaxer> not efficient anyway, but *maybe* useful
<Regenaxer> But now I tend to give up 32 bit support
<beneroth> you mean the current pil32 edition?
<Regenaxer> Seems it needs ugly constructs
<Regenaxer> no
<beneroth> or you mean LLVM on x86 ?
<Regenaxer> no
<Regenaxer> :)
<Regenaxer> Generate LLVM-IR that runs on 32 bits
<Regenaxer> despite the Pil VM is 64 bit
<Regenaxer> pil32 is a completely different beast
<Regenaxer> and Ersats again
<Regenaxer> Ersatz
<Regenaxer> I want to map pil64 to LLVM
<Regenaxer> (and thought we might get something analog to pil64's emu running on 32 bits)
<Regenaxer> A cludge anyway
<Regenaxer> The question is how much 32-bit support for Pil is really needed in the future?
<Regenaxer> I use emu on Android
<Regenaxer> but the few users I have gradually got 64 bit mobiles meanxhile
<Regenaxer> aw- uses pil on 32 bit, right?
<Regenaxer> But how about the future?
<Regenaxer> pil32 and mini will stay around, just no longer maintained
<Regenaxer> PilMCU and PilOS not sure yet
<Regenaxer> I expect LLVM-IR can be translated to Verilog too, but have not investigated yet
<beneroth> so... you mean in pil21 code would all be kinda pil64, technically the VM running on 64bit, though it will run on 32bit systems (hardware, OS) too ?
<beneroth> are we talking about source code compatibility or hardware/platform compatibility.. or both?
<beneroth> What will be lost?
<Regenaxer> "kinda pil64" yes, but 32 bit hardware no
<Regenaxer> Lisp source is the same
<beneroth> ok, so pil21 will not be running on 32bit hardware (even when LLVM should support it) ?
<Regenaxer> implementation pilAsm -> Mock-Pil
<beneroth> Mock-Pil + pil + LLVM = building pil21 ?
<Regenaxer> It is not LLVM not supporting it
<Regenaxer> I dont find a way to generate LLVM that runs on both
<Regenaxer> MockPil is the source in pil21.tgz
<Regenaxer> PilAsm:
<beneroth> so.. two LLVM frontends would be needed, to produce 64bit and 32bit binaries?
<Regenaxer> # (car 'var) -> any(code 'doCar 2) push X ld X E ld E ((E CDR)) # Get arg eval num E # Need variable jnz varErrEX ld E (E) # Take CAR pop X ret
<Regenaxer> oops
<Regenaxer> cant paste here
<beneroth> nvm
<Regenaxer> no
<Regenaxer> no 32 binaries
<Regenaxer> like current pil64
<beneroth> yes, I understand that is the roadmap now
<Regenaxer> Pil64 and pil21 use 64 bit words
<Regenaxer> in cells
<Regenaxer> 32 bit machines have 32 bit pointers
<beneroth> so the question is: to have 32bit binaries, an additional pil implemention (could be on LLVM) would be required, yes?
<Regenaxer> I dont find a clean way to express this in LLVM-IR
<beneroth> yeah I understand
<beneroth> thought so :)
<Regenaxer> Then we dont need llvm, just use current pil32
<beneroth> T
<Regenaxer> It makes only sense if the pil21 implementation compiles and runs also on 32 bit
<beneroth> though maybe the differences between two such implementations in MockPil would maybe be more similar and easier to maintain than current C-version and pil21...
<beneroth> just theorizing here
<Regenaxer> no, it is a nightmare
<Regenaxer> very different
<beneroth> ok
<mtsd> Hello beneroth
<Regenaxer> as new pil32 and pil64
<beneroth> hi mtsd :)
<Regenaxer> s/new/now
<beneroth> the pointer size makes a bigger difference than the compiler
<Regenaxer> emu now maps the 64 bit arch to C
<mtsd> Maybe we could ask the mailing list, and here in IRC, to see how many are really using 32 bit?
<Regenaxer> yes
<Regenaxer> mtsd, right
<beneroth> I don't have pil32 in use anywhere, afaik.
freeemint has joined #picolisp
<Regenaxer> and how the future will be
<beneroth> I have unused 32bit hardware lying around though ^^
<mtsd> As for myself, I no longer have any 32 bit hardware around
<Regenaxer> same here
<Regenaxer> I have one old ThinkPad
<Regenaxer> from 2005
<Regenaxer> but tough to install new os on it
<Regenaxer> I think I will never use it again
<mtsd> Oh, come to think of it, I do have an old, 32-bit, netbook..
<beneroth> what about the mobile front? a few years ago you had issues with client company using 32bit androids, no?
<beneroth> though yeah, iOS compatibility would be a advantage probably worth that cost
<Regenaxer> yes, as I said above, most have new devices meanwhile
<beneroth> (if Apple allows pil VM in store.. well possible that they will not)
<beneroth> ok
<Regenaxer> thats another problem ;)
<mtsd> I could probably fit 32-bit Debian on the netbook, if you need help testing something
<Regenaxer> thanks!
<mtsd> Anytime! :)
<Regenaxer> tankf33der has any conceivable system it seems :)
<beneroth> :D
<mtsd> More and more Linux distributions are dropping 32-bit, apparently
<Regenaxer> yeah
<Regenaxer> Apple too
<Regenaxer> So, OK, lets forget 32 bit for now
<Regenaxer> If *really* necessary, we can re-consider
<mtsd> Maybe time to take the plunge with Pil too, if it means easier maintenance?
<Regenaxer> Lets first see how pil21 works out
<Regenaxer> exactly
<Regenaxer> much more clean in 64-only
<Regenaxer> If *really* necessary, we can re-consideri
<Regenaxer> oops
<mtsd> I would love to be able to help out with the low level, implementation stuff. But I would need too much guidance and hand-holding to do so, and that would steal too much of your time, I'm afraid
<Regenaxer> Welcome!
<Regenaxer> Most issues are not pil but llvm
<Regenaxer> The optimization has to be investigated
<mtsd> I guess I could start by reading the llvm docs, and see if I can wrap my head around that
<Regenaxer> :)
<mtsd> I have to apologize in advance for all the stupid questions I will ask.. ;)
<Regenaxer> What I want to achieve is have a LLVM-IR base system in the distro, so that bootstrapping is easier than ow
<Regenaxer> No worry!
<mtsd> Application level type programmer trying to understand how things really work. That's me :)
<Regenaxer> Always good to learn such things
<mtsd> Yes, and that is something I would really like to learn. Maybe a good opportunity to start now
<Regenaxer> T, probably llvm has a future
<Regenaxer> as a general architecture
<Regenaxer> Not because it is so good, but because so many jumpen onto the waggon
<mtsd> Yes, it pops up everywhere these days.
<Regenaxer> T
<beneroth> so it achieves the old Java dream... all programming happening on that VM
<mtsd> And focusing on 64-bit, trying to understand llvm, is more than enough for me. I have my work cut out just trying to get into that..
<Regenaxer> OK :)
<Regenaxer> You don't need to study all those C++ libs in llvm
<Regenaxer> Pil won't need them
<mtsd> But it would be really nice to understand the inner workings. I have been using Pil for some time now, and it feels like the next step to take. Good project for me, on a personal level as well.
<Regenaxer> But llvm-ir and the 'opt' tool later
<Regenaxer> yeah, good thing
<beneroth> pil inner workings and glueing them to LLVM are different things :)
<beneroth> T
<Regenaxer> yeah
<mtsd> If I don't try, I could just keep using Python or Perl or some other language without really understanding what they do. Stuck in application land forever :)
<beneroth> both is good to understand
<beneroth> but pil inner workings are surely way easier xD
<beneroth> you ever programmed C with some pointer arithmetic?
<Regenaxer> What I do at the moment is rewriting the pilAsm stuff in MockPil
<mtsd> Yes, in the past
<beneroth> pil VM is all just pointers after the parsing step
<beneroth> Regenaxer, I see
<beneroth> Regenaxer, what does interpret the MockPil ? the LLVM-frontend ?
<Regenaxer> I would say no interpretation
<Regenaxer> MockPil is compiled to LLVM-IR
<Regenaxer> LLVM-IR replaces pilAsm
<Regenaxer> instead of A, C, E, X etc
<Regenaxer> we have SSA
<Regenaxer> Static single assignment
<Regenaxer> You can think we have an unlimited set of registers
<beneroth> ok
<beneroth> oh
<beneroth> interesting
<Regenaxer> Every one is assigned only *once*
<Regenaxer> and never changed
<beneroth> so LLVM tries to optimally map the used registers to the hardware ones?
<Regenaxer> Kind of sick, but useful
<beneroth> and emulates the rest?
<Regenaxer> exactly
<beneroth> oh
<Regenaxer> can and must be optimized, but I dont have to care
<Regenaxer> What is tedious for implementing pil is that it is statically typed
<Regenaxer> and pil data have no clear type
<Regenaxer> all is "any" :)
<Regenaxer> So I must de a lot of fuzz to get that straight
<Regenaxer> But that's all solved
<mtsd> All has the potential to be anything. Almost like quantum mechanics ;)
<Regenaxer> I understand that such strongly typed llvm code can be much better optimized
<Regenaxer> yeah, kind of :)
<Regenaxer> s/must de a lot/mus do a lom
<Regenaxer> penti o <-> e ;)
<mtsd> So, PilAsm was turned into assembler via gcc before. Now MockPil is turned into LLVM-IR? Is that how it works?
<Regenaxer> No, PilAsm was turned into assembler by PicuLisp
<Regenaxer> gcc then assembled it into machine code
<mtsd> Ok
<Regenaxer> And yes, MockPil is turned into LLVM-IR
<Regenaxer> It looks like normal pil almost
<Regenaxer> but isn't
<mtsd> I got that right at least, haha
<Regenaxer> :)
<mtsd> It is dangerously comfortable to just igore these things and only use a language to write applications :)
<mtsd> But less satisfying in the long run
<Regenaxer> T, better tu understand the internals
<beneroth> good to understand internals, but better for sanity to work on application level instead having to deal with eccentric hardware and compilers
<mtsd> haha, problaby true, beneroth.
<Regenaxer> needs good abstractions
* beneroth learned from Regenaxer that the only (long-term) good abstractions are the ones which don't add restrictions other than what is absolutely necessary to make it meaningful
<beneroth> "unintended" restrictions happen so quickly... though unintended often just means "dev doesn't care, who would ever use it THAT way anyway..:"
<beneroth> then some time later you find then the clever use case for THAT way
<Regenaxer> yes, eg 32 bit support ;)
<beneroth> haha, didn't mean to relate to that ;-)
<Regenaxer> :)
<Regenaxer> Lets see
<mtsd> Well, 64-bit and llvm seems to be where large parts of the world if going. Pil has evolved through many different generations of technology already.
<mtsd> So the abstractions in Pil seem to be quite well chosen :)
<Regenaxer> :)
orivej has quit [Ping timeout: 276 seconds]
<beneroth> MockPil looks really very picolispy, even more than pilASM :)
<Regenaxer> yes, pilAsm is not Lisp syntax
<Regenaxer> In my mind MockPil maps to LLVM-IR
<Regenaxer> But looking at the generated LLVM-IR is a culture shock for a PicoLisper I think
<mtsd> Can I download the current, work-in-progress, version of Pil21 anywhere? To look at MockPil etc
<mtsd> Thanks!
<Regenaxer> Only a proof of concept so far
<Regenaxer> very few functions actually implemented
<Regenaxer> you see them in SymTab in src/glob.l
<mtsd> Yes, opened glob.l now, looking around
<Regenaxer> Mostly global symbols in SymTab
<Regenaxer> needed I, N etc. for testing the 'native' skeleton
<Regenaxer> I wanted to make sure first that 'native' is possible again
<Regenaxer> BTW, this is the only docs I used:
<mtsd> Thank you, I will have a go at reading the docs, for a start
<beneroth> :)
<beneroth> bbl
beneroth has quit [Quit: Leaving]
<Regenaxer> tankf33der, how does it come you can test on so many systems? Do you own a computer-museum?
<tankf33der> :)
<Nistur> mornin'
<Regenaxer> Hi Nistur!
<Nistur> hello :)
rob_w has quit [Quit: Leaving]
mtsd has quit [Quit: Leaving]
freeemint has quit [Remote host closed the connection]
freeemint has joined #picolisp
beneroth has joined #picolisp
freemint has joined #picolisp
freeemint has quit [Read error: Connection reset by peer]
orivej has joined #picolisp
<beneroth> Regenaxer, are you here?
<beneroth> Regenaxer, nevermind
<beneroth> afk
vikid has joined #picolisp
vikid has quit [Ping timeout: 240 seconds]
<Regenaxer> Hi beneroth, yes
vikid has joined #picolisp
<Regenaxer> Hi vikid! Been a long time o/
vikid has quit [Ping timeout: 240 seconds]
Seteeri has joined #picolisp
<beneroth> back
<Regenaxer> Hi beneroth
<beneroth> hi Regenaxer :)
<beneroth> I pondered about a way to look out for symbol name clashes. e.g. having everything using transient names in a library, and then after loading (while still in the transient scope, so in in the file) check for clashes and then intern
<beneroth> but yeah.. I realized (import) is for that :)
<beneroth> (independent of namespaces)
<Regenaxer> Indeed, import from transient
<beneroth> yep, exactly
<beneroth> Regenaxer, or even better, using (name) with two args?
<beneroth> e.g. (name "foo" 'bar) =
<beneroth> hmm..
<beneroth> the ref has an example: (intern (name (zap 'car) "xxx") T)...
<Regenaxer> renaming
<Regenaxer> Not sure if a good idea
<Regenaxer> I'm more and more into namespaces, I think it is best
<Regenaxer> Very heavy use in pil21 build
<beneroth> use case (might be bad idea): 1) definitions, e.g. functions and globales 2) rename, still using transient names 3) import some/all transient names
<Regenaxer> src/lib/llvm.l
<beneroth> T
<beneroth> I saw
<Regenaxer> It redefines part of Pil so that it compiles
<Regenaxer> Namespaces are also hard sometimes
<Regenaxer> I had to be very careful when to override what
<beneroth> yeah
<Regenaxer> (with local mainly)
<Regenaxer> :)
<beneroth> I have two issues with namespaces for my use case: A) namespace ordering has to be strict. difficult to handle later additions of additional namespaces, no?
<Regenaxer> Why?
<beneroth> because the same earlier order has to be ensured
<beneroth> no?
<Regenaxer> I even change the order usually
<Regenaxer> When defining it is the first namespace
<Regenaxer> at runtime more in the back usually
<beneroth> T, got that
<beneroth> yeah, I mean at runtime
<beneroth> might not be a real issue
<beneroth> the other point is: B) limits for use with DB
<Regenaxer> I use it with DB in PilBox a lot
<beneroth> technically because parsing vs. limited reversal of parsing
<Regenaxer> I think DB is not special here
<Regenaxer> It is always necessary to be careful :)
<beneroth> T
<beneroth> well storing code in DB as +List +Any is a problem, but storing code that way is probably a dumb idea anyway
<Regenaxer> not easy, unfortunately
<beneroth> then the storing happens after parsing, so its already pointers. and written into db will be symbol names, but with no regard for namespaces
<Regenaxer> You must just take care that the order is the same at reading and at writing
<beneroth> probably better to store code as files
<beneroth> exactly
<beneroth> and in my use cases I want to change this orders and number of namespaces over the lifetime of a db/application
<Regenaxer> Transients will not share when reading from PLIO
<Regenaxer> Changing is perhaps good
<beneroth> the point is, I want the references
<Regenaxer> we must develop our strategies
<beneroth> T
<beneroth> specific to use case
<Regenaxer> Which references?
<beneroth> reference of an Entity or function or method in code. I want to store that code, load it, but also figure out "Entity X is used there, there and over there"
<Regenaxer> ok
<beneroth> so.. either save in structures made for that - complex.
<beneroth> or very simple: files.. and grep, or a pil script which like (lint) understands the pil source code :)
<beneroth> and on top of that I would like to have modularization.. could be done with namespaces, but tricky to get it always right
<beneroth> could be done with symbol naming conventions. could lead to overly long symbol names, but otherwise ok.
<beneroth> and other ways are possible.
<Regenaxer> Probably
<beneroth> you agree so far with my view?
<beneroth> it's no critic on your general system, it is great ;-)
<Regenaxer> :)
<beneroth> I just have to figure out the best way for my special needs
<beneroth> best = flexible and maintainable. the law of picolisp states: KISS
<Regenaxer> yeah, you are entering new realms
<beneroth> yeah there is some essential complexity to it (in the No Silver Bullet sense)
<beneroth> we have to document lib/svg.l :)
<Regenaxer> true
<Regenaxer> afp
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 240 seconds]
Seteeri has quit [Ping timeout: 276 seconds]
stultulo has joined #picolisp
stultulo is now known as oldf8l
oldf8l is now known as stultulo
f8l has quit [Ping timeout: 265 seconds]
stultulo is now known as f8l