85300+ entries in 0.051s
ave1: I've played little with
the bb-runtimes but
the whole build process is based python + gprbuild and needs at least ada 2017 sources.
phf: asciilifeform: yes,
they do, i did some research into subj and it's literally java on winblows
ave1: btw I understood
that esa still uses Leon processors with ADA
phf: i suspect spaceprobes people don't ever need
to start a fresh program either, in a conventional sense
ave1: the same with interfaces.c, a version without secondary stack can be easily made (I have one already, simple method of cutting out functions), but is
then not really ada standard anymore.
ave1: for overview
there will probably will be about 6 flavours of zfp I
think based on: MUSL C, X86_64 ASM + linux, X86_64 ASM + no os, AARCH64 + linux, AARCH64 + no os.
ave1: phf, yes
that's
the right approach
phf: i
took a different approach, i wrote _to ada standard_ with
the idea
that each interface can be substituted with a custom system specific replacement. for example my character_io is a new_line aware replacement of
the original,
that relies on ada.sequential_io. now if i wanted
to retarget
to small machine, i'd write a custom sequential_io
that uses machine specific calls for byte read/write
☟︎ ave1: yes
the other
thing is
to get
the os out and I'm reading your code
ave1: phf, asciilifeform's ffacalc uses only a few C functions all for IO / exit and command line arguments. I just have
to provide
the right functions in
the ZFP library for ffacalc (currently first on conveyor but also some real life priorities
these weeks)
phf: i'm starting
to
think
that maybe it doesn't (my memory of logs are hazy on
that point, perhaps ave1 mentioned
that he's working on getting ffa_calc working), because i believe you're also using interfaces.c at least
to declare
the
types
that you get in/out of c system calls
phf: asciilifeform: i
thought
that you were arguing
that
the subset of ada runtime
that's included in zfp "ought
to be enough for everyone", since at
the moment i believe it compiles ffa, my apologies.
phf: interfaces.c is not a libc concern, it's an ffi.
the situation is
that C can't be linked
to an Ada, even if
the C part has _no libc_ in it
☟︎ a111: Logged on 2018-07-06 17:09 asciilifeform: 'make emu' builds variant
that runs in qemu and (if you have x86-64 qemu) boots it. 'make sage' ditto but boots on a cold sage ( see
http://www.loper-os.org/?p=1887 & elsewhere ) . 'make sage-warm' boots on a warm sage.
phf: but i remember diana_coman saying something about her code not compiling in ave1's because interfaces.c is not included. i'm not sure if she was
talking about
the former or
the later
phf: oh i was
talking about
the later, since
that's
the avant guard of
the ada situation
phf: or is
tmsr ada whatever ave1 put into his musl build, which is, worse, a political situation. diana_coman can argue for her ffi stuff
to be included, should i be arguing for my get/put stuff
to be included?
☟︎ phf: as far as ada is concerned,
the
tmsr ada is a subset of standard,
that only exists in your head, and can be somewhat inferred from ffa.
that's no standard
☟︎ phf: asciilifeform: oh yeah, i get it,
the approach requires a GOST cpu with a GOST bus etc. etc. right now
the situation is mildly depressing (though perhaps
that's not
the right word), even Ada standard
turned out
to be dodgy (very precisely specifies some shitty solutions)
☟︎ phf: standard by
they way allows for a subset of "such horrors" in form of symbol-macrolet
phf: particularly since
that particular autoload machinery was already in genera
phf: you should know
that common lisp standard is not
the whole, but rather
the
top, i.e.
the commonality of features between multiple lisp machines.
there are parts
that explicitly under specified
to allow for a variety of behaviors
phf: asciilifeform: you can still add a feature without violating
the standard, but
there's
tones of features like
that
that can only exist as part of compiler and also not violate a standard. lazy symbol is a particularly good example:
the symbol behaves according
to standard, but accessing its value "stops
the world" for all practical purposes, calls some other machinery, "resumes
the world" with
the value provided by machinery.
mats: the stamp sized
tegs i’ve seen are pricy
though, ranging from $5-15
phf: no why?
they don't have
to
mats: asciilifeform:
this parasitic relay incorporates esp8266 in urban environment
phf: well, 100 ln patch
to
the compiler, because it can't be done as a user proggy (e.g. (symbol-value 'foo)
triggers a mechanism of some sort, without an indirection)
phf: for example in naggum's "history of
time" he
talks about having a package
tz with symbols for all
the
timezones, and if you access say
tz:est or whatever,
the
timezone is
transparently loaded. can only be done in allegro
☟︎ phf: d crannies
that allow for superior experience
phf: allegro is batteries included, and if
they're not
they'll add
the batteries for you, so for most practical purposes you don't need
to fuck with quicklisp and
the variety of dodgy quicklisp packages. but allegro generally made a lot of, i don't know how
to put it, old skill lisp-machine-y decisions
to make sure your development experience is superior. instead of being sticklers for
the standard, and not venturing outside of it,
they kept adding nooks an
phf: well lispworks has capi,
that doesn't have an non-proprietary equivalent, so if your work requires any kind of gui, you're stuck with some very dodgy solutions (in
the early days i even used emacs/slime as a gui backed by ccl)
☟︎ a111: Logged on 2018-07-18 10:20 mats: a peltier
teg looks ideal for
the parasitic relay power plant
phf: are you
talking in
the context of
tmsr, or your commercial work? i had both of
them bought at some point, back in my common lisp consulting days it was a no brainer,
the cost was always a small fraction of
the contract, but
the
technical advantage immense. but
then i don't have
the source code for many
things
that i make my food with
☟︎ phf: but i also don't know how you get
the source from lispworks, if at all.
they have a fixed price list
though.
phf: asciilifeform: you have
them backwards
a111: Logged on 2018-07-18 00:33 asciilifeform:
http://btcbase.org/log/2018-07-18#1835659 << iirc allegro was moar complicated
than
this,
tho
tbf i am unsure whether less or ~more~ scammy . it was a nonfixed price (no cost for src actually but had
to 1) be existing customer and 2) sign seekricy contract ) and price of being customer in
turn wasn't 'fixed' ( 'lispworks' co. iirc charged royalties ) . as for 'specified',
this was 1 of
the rare products where yes specified ( common l
phf:
http://btcbase.org/log/2018-07-18#1835681 << in allegro's case
the model was (is?) a vendor partnership,
they don't sell
to all comers. you have
to have a sit down where you essentially pitch your project
to
them and work out a payment structure, some combination of buy in, royalties, etc. similar
to some of
the banking vendors i worked with, like kx
☝︎ phf: the usgistic appearance of
the site is a ruse, very similar
to soekris in
this respect.
the main difference from soekris is
that
there are no manufacturing costs, so can be "alive" for a price of couple of servers
phf:
http://btcbase.org/log/2018-07-18#1835696 << i believe at least in
the case of allegro
the ownership is
the dks/symbolics model (or perhaps soekris model), guy who made it sells it and
there's enough sales money
to periodically fund developers, add new features, etc (considering
that some of
the contracts are finance and gov)
☝︎☟︎ esthlos: diana_coman: heh, it was supposed
to be "model"
diana_coman:
http://btcbase.org/log/2018-07-18#1835801 -> right, I can see
that reading although it wasn't my point; by "their call" I mean
that
they get
to evaluate (through whatever process, possibly including "what is wrong with you" or anything else) and decide, not
that
they ignore upfront ; how would ignoring of author even make sense if code is not ignored ?
☝︎