morganw has quit [Remote host closed the connection]
random-nick has joined #commonlisp
makomo has quit [Quit: WeeChat 3.4]
mrcom has quit [Quit: Leaving]
igemnace has quit [Quit: WeeChat 3.5]
orestarod has joined #commonlisp
kpoeck has quit [Quit: Client closed]
Oddity has quit [Ping timeout: 258 seconds]
frgo has quit []
frgo has joined #commonlisp
Brucio-61 has quit [Remote host closed the connection]
Brucio-61 has joined #commonlisp
pillton has quit [Quit: ERC 5.4 (IRC client for GNU Emacs 28.1)]
mrcom has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
lisp123 has joined #commonlisp
tyson2 has joined #commonlisp
Spawns_Carpeting has quit [Ping timeout: 244 seconds]
Spawns_Carpeting has joined #commonlisp
lisp123 has quit [Quit: Leaving...]
aartaka has quit [Ping timeout: 246 seconds]
aartaka has joined #commonlisp
taiju` has joined #commonlisp
taiju` is now known as taiju
dra_ has joined #commonlisp
<Guest74>
is there any vector graphics stuff that isn't based on cl-vectors?
<Guest74>
I'm trying to think of what's a good way to store paths, maybe vg in general.
<beach>
"store" paths?
<Guest74>
some formatted object
<Guest74>
structured
<beach>
I mean "store" in a file, in a database, something else?
<Guest74>
no, just in memory to access.
<Guest74>
if there are other formats out there it'd be nice to have access to them.
<beach>
I am not sure what you need, but CLIM/McCLIM can draw arbitrary polygons and other shapes, including Bezier curves.
<Guest74>
it's not about drawing them, it's about how they're structured in memory.
<Guest74>
does mcclim have a way to specify a path, or does it do path building internally?
<beach>
I guess I am lost. Sorry.
<Nilby>
Guest74: lists of structs, or lists of standard-objects that have a print-object and maybe a reader macro that makes them readable
<Guest74>
Nilby: that's pretty close to how cl-vectors does it. I'm wondering if there is anything else.
leeb has joined #commonlisp
<Guest74>
they just wrap a struct around two lists of point and interpolation.
<Nilby>
You can convert them to vectors to speed up some operations
<Guest74>
whoops, they probably are.
<Guest74>
yeah, they are.
<Guest74>
I'm just thinking if I don't need to add any functionality to this format I might as well just use it.
<Nilby>
Or build them as adjustable vectors
<Guest74>
cl-vectors makes them adjustable will fill pointers.
<Nilby>
If you make the as objects you can extend the node types, but I've seen them as structs in production
<Guest74>
what other type of nodes would you want?
<Nilby>
one could imagine adding color or texture for vertex shading
<Guest74>
that's separate from a path though.
<Nilby>
or other geometric types like tensors
<Guest74>
i think you can still do that with paths in cl-vectors.
<Guest74>
they put it on you to add methods to interpolate say along 3 dimensions, so only those methods that you added need to know about how you represent a 3d point. probably some declarations that wouldn't like it.
<char[m]>
If one of the slots of a clos object needs a reference of the object to be created, what is the best way to do that? Something like (let ((a (make-instance 'obj :s (... a))))
<jackdaniel>
that won't work, there is no letrec in cl. (let ((a (make-instance ...))) (setf (s a) a))
<jackdaniel>
or do it in initialize-instance method
<Guest74>
jackdaniel: does mcclim have facilities to make/construct/edit/store vector paths?
pjb has joined #commonlisp
<char[m]>
jackdaniel: thanks
<jackdaniel>
paths are subclasses of region in mcclim, there are classes representing i.e polybeziers and such.
<jackdaniel>
currently there is no class representing paths with components of a different type
<Guest74>
ok, thanks.
<jackdaniel>
i.e line + arc, but this could be implemented as a region union
<jackdaniel>
that said region union would not be sufficient for rendering joints, so probably a separate class would be needed
<Guest74>
I guess I wont abstract over cl-vectors if there isn't really anything else.
<jackdaniel>
beach: contemporary rendering api allow constructing paths with operators like (line-to <current-path> <new-point>) -> <extended-path>; for example duim (dylan user interface manager, clim sybling) has such protocol
<Nilby>
jackdaniel: +1 for knowing about DUIM :)
<jackdaniel>
:)
* Nilby
was a Dylan fan for a while
<Guest74>
Welp, that's one less thing to do.
<Guest74>
Can anybody think of any path building stuff not covered by svg? Cause then i'll just leave that alone as well.
<Nilby>
I can think of a lot things, like stuff useful in parametric constraint CAD, but if you need more, you can alwyas hack more
<Guest74>
such as? that appears to me to be manipulating the path.
<Nilby>
nodes in graphic objects can have matierials, forces, attachments, etc.
<Guest74>
oh, i guess I better add catmul-rom as cl-vectors has it.
<Guest74>
I only added what was necessary to parse svg paths.
<Nilby>
path elements in svg can have a lot of mostly useless crap in them
<Guest74>
perhaps it'd be more correct to say parse the D element in svg paths.
<Nilby>
yes, that's more like the traditional way, because otherwise you have arbitrary css and javascript, which one can do much better in lisp with CLOS
<Guest74>
Yes, I don't plan on supporting any of that in displaying svg.
waleee has joined #commonlisp
<Nilby>
I think how much stuff is in SVG is actually a sign of the how the javascript object model isn't good enough for big systems
<Guest74>
well, it makes it easy to store stuff in. I'd like a lisp format for that, but...
<Nilby>
well, thankfully anything that's xml can be s-exp
kcymo has joined #commonlisp
taiju has quit [Ping timeout: 244 seconds]
kcymo is now known as dBc
dBc has quit [Quit: leaving]
dBc has joined #commonlisp
dBc has quit [Client Quit]
dBc has joined #commonlisp
dBc has left #commonlisp [#commonlisp]
yewscion has joined #commonlisp
dBc has joined #commonlisp
dBc has quit [Quit: leaving]
dBc has joined #commonlisp
dBc has quit [Quit: leaving]
ttree has joined #commonlisp
leeb has quit [Quit: WeeChat 3.4.1]
e3d3 has joined #commonlisp
<e3d3>
total-noob-question: how can I test if the value of a variable is equal to one of the values in a list ?
<e3d3>
I tried it with: (eq myvar (or one two three))
<e3d3>
but that returns ALWAYS the first list element
<rotateq>
e3d3: EQ is for pointer-wise equality testing. And you could use one of FIRST, SECOND, ..., TENTH for example.
<e3d3>
Correction, I tried: (eq myvar (or 'one 'two 'three))
<e3d3>
rotateq: Thanks, I'll read about FIRST, SECOND etc
<rotateq>
Ah okay, so see that OR is a macro that expands to a correspong IF or COND form. Then you realize why the first non nil value is taken.
<Alfr>
e3d3, you want find or position, I think.
<rotateq>
Yeah there are some possibilities.
<e3d3>
Alfr: I only want to test if a variable has a value that is in some list. I don't care about its position in the list, but maybe find is what I want. Thanks
<Nilby>
e3d3: You could use FIND or MEMBER too
<beach>
e3d3: But POSITION return NIL if and only if it is not in the list, so it works as well.
<rotateq>
Then MEMBER or FIND and you can specify the right test additionally.
<beach>
e3d3: I would use MEMBER in this situation.
<rotateq>
Okay hopefully not too much information right now.
<e3d3>
not at all
<Alfr>
beach, ah ... member, thanks. That's the one I couldn't recall earlier. :)
<e3d3>
I use Emacs, can easily see the descriptions of these commands, I that of MEMBER was what I was looking for.
<rotateq>
e3d3: I just try to imagine how the person at the other end might feel as I know this situation reasonably well myself.
<e3d3>
I understand, without Emacs it would have been different
<e3d3>
Thank you all, I'm going to exercise my MEMBER
e3d3 has left #commonlisp [rcirc on GNU Emacs 27.1]
<rotateq>
Good, so MEMBER is for lists and returns the nth cdr starting with the found element, whereas FIND could be used for sequences (basically lists and vectors) and just returns the element itself.
<beach>
Indeed.
icepic1984[m] has quit [Quit: You have been kicked for being idle]
<Nilby>
i got trouble membering member since memq got rplaca'd
icepic1984[m] has joined #commonlisp
icepic1984[m] has left #commonlisp [#commonlisp]
vassenn has joined #commonlisp
<Guest74>
is there a prevalent boundingbox/region format or a reason to choose coordinates over coord + width height?
<Nilby>
coordinates are more general, e.g. you could pass the same data to other shaped region functions. depending on what you're doing you can save an addition/subtraction
<Nilby>
also e.g. if you use coordinates you can move the box by mapping addtion
<Guest74>
that would would work the same way subject to whether you are using top left, center, or bottom left for your first point.
<Nilby>
it's traditional to do lower left than upper right, which is like the postscript/pdf/svg/cairo etc graphics model
<Guest74>
i don't know about the rest, but pretty sure svg is point + width height.
dra_ has quit [Quit: Leaving]
dra has joined #commonlisp
<Nilby>
hmmm. i guess they must have changed it for compatibility with th html/javascript world or something. i worked on a pdf/postscript engine
<Nilby>
the svg people are clearly up to no good, since they added animation and scripting, practically insuring their software monopolies
<rotateq>
Now I realized which context the initial question had, McCLIM. :)
<Guest74>
e3d3's?
citizenandrew has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
karlosz has joined #commonlisp
Bike has joined #commonlisp
xantoz has quit [Ping timeout: 246 seconds]
citizenandrew has quit [Quit: Client closed]
karlosz_ has joined #commonlisp
karlosz has quit [Ping timeout: 258 seconds]
karlosz_ is now known as karlosz
aartaka has quit [Ping timeout: 246 seconds]
z4kz has quit [Quit: WeeChat 3.5]
zak1 has joined #commonlisp
zak1 is now known as z4kz
karlosz has quit [Ping timeout: 240 seconds]
notzmv has quit [Ping timeout: 244 seconds]
triffid has quit [Remote host closed the connection]
triffid has joined #commonlisp
<rotateq>
Guest74: No yours. :) I didn't make the connection with boundingbox immediately, but I should have.
<rotateq>
Why do you ask and what do you want to do? The repo seems to be with Python.
<boka>
correct, i also want to see if common lisp have such abilities :) , they look pretty nice so i cant waited to see if cl can do :)
<rotateq>
The question is not if, but how.
<boka>
:)
Sauvin is now known as Lemniscate
Lemniscate is now known as Sauvin
aartaka has joined #commonlisp
Oladon has joined #commonlisp
prokhor_ has joined #commonlisp
<Guest74>
rotateq: my initial question had nothing to do with mcclim.
prokhor__ has quit [Ping timeout: 260 seconds]
<rotateq>
Guest74: Okay. I can live with not knowing it then.
anticomputer has quit [Remote host closed the connection]
aartaka has quit [Ping timeout: 255 seconds]
aartaka has joined #commonlisp
anticomputer has joined #commonlisp
attila_lendvai has joined #commonlisp
notzmv has joined #commonlisp
pvalenta has quit [Ping timeout: 246 seconds]
pvalenta has joined #commonlisp
Dynom has quit [Quit: WeeChat 3.5]
aartaka has quit [Read error: Connection reset by peer]
aartaka has joined #commonlisp
triffid has quit [Remote host closed the connection]
triffid has joined #commonlisp
tyson2 has joined #commonlisp
Oladon has quit [Quit: Leaving.]
attila_lendvai has quit [Ping timeout: 260 seconds]
<Spawns_Carpeting>
whats the deal with pathnames? are they able to support linux paths with non ascii or unicode bytes in them?
cage has quit [Quit: rcirc on GNU Emacs 27.1]
<Spawns_Carpeting>
if they are, I am curious exactly what type gets returned when doing things like (pathname-directory p)
<Spawns_Carpeting>
normally that returns a list of strings except for the first element which is a symbol of either :HOME or :ABSOLUTE
<Spawns_Carpeting>
not HOME, RELATIVE
<Spawns_Carpeting>
i also wanted to ask, what makes you guys prefer CL over scheme?
morganw has joined #commonlisp
<pjb>
Spawns_Carpeting: first, you have to realize that posix paths are vectors of octets, with only two special bytes: 0 and and 47. 0 terminates the path, and 47 separates the components.
<pjb>
Spawns_Carpeting: when you see something like /bin/ls the system actually sees: #(47 98 105 110 47 108 115) !!!
<pjb>
(plus the terminating 0 sorry)
boka has quit [Quit: Client closed]
<Spawns_Carpeting>
i am not sure whether that is a cool thing or disturbing
<pjb>
Spawns_Carpeting: It should be disturbing. Notably, because users want to interpret those octet sequences as text, using some specific encoding system!
<Spawns_Carpeting>
yes that seems problematic
<pjb>
Now, CL pathnames are structures made of CL string components. CL strings are vectors of characters. There's no octet there, no encoding, only characters.
<pjb>
So CL pathnames need to be translated into path by the implementation. Note: there's no public CL operator to do that! It's implicit in OPEN, and other file operators.
<Spawns_Carpeting>
what exactly is the difference between an octet and a character in this case?
<pjb>
There's one translation which is to namestrings. CL namestrings are strings (sequences of characters), that when encoded using the default system encoding for paths, gives the posix PATH.
<pjb>
Spawns_Carpeting: #\é is a character, 233 is an encoding of that character in ISO-8859-1, (195 169) is an encoding of that character in UNICODE UTF-8.
<pjb>
namestrings stop at #\é. You need an implementation dependent way to specify the encoding to use to compute the path.
<Spawns_Carpeting>
oh so a character is not like in c++ where its just a byte, and strings aren't just vectors of bytes
<pjb>
Most implementation use the locale environment variables. But some have additionnal variables (eg. defined in a EXT or other extension package) to specify them.
<pjb>
Spawns_Carpeting: correct.
<pjb>
CHARACTER is a distinct data type.
<pjb>
Now, namestrings obviously have a syntax that depends on the platform. For posix, it's /foo/bar ; for MS-Windows it's c:\foo\bar, for MacOS, it's MyDisk::foo::bar
<pjb>
To be able to process pathnames whatever the platform syntax for paths, you can use physical pathnames.
<pjb>
And to be able to process pathnames whatever the installation, you can use logical pathnames.
<pjb>
The translation from physical pathnames to namestring (and vice-versa) is implementation (and platform) dependent and provided by the implementation.
<pjb>
The translation from logical pathnames to physical pathnames is given by a user supplied map in *logical-pathname-translations*
vassenn has quit [Quit: Good bye!]
<Spawns_Carpeting>
since pathnames are structures made of CL strings, and strings are CL chars, what happens with OS paths that contain bytes that don't correspond to a char in CL?
<pjb>
Note: some path (vectors of octet) may not be decodable, given a selected coding system. So some files may be inaccessible, if you don't select the right encoding.
<pjb>
So (directory "*") may not be able to return all the paths available in the file system.
<pjb>
If you want to do that, you will have to use a POSIX API, such as ftw, or opendir, etc. (using FFI or an implementation specific POSIX package).
<pjb>
But in general, users aren't too wild, and most path are decodable using usual coding systems, either iso-8859-1 or unicode utf-8.
<pjb>
Note however, that with unicode utf-8 different systems may use different normalizations, so the vector of octet may be different for the same string.
<Spawns_Carpeting>
thank you by the way pjb, this information has been very helpful
<Spawns_Carpeting>
yes I was just going to say that
manykwh has quit [Client Quit]
manykwh has joined #commonlisp
<pjb>
Spawns_Carpeting: the simpliest, is to let the user rename the bad paths to something sane, so they can be processed by CL (and other systems). The common advice is to use [A-Z0-9]{1,8}.[A-Z0-9]{1,3} We may admit [A-Z0-9a-z], and as a lisper, I use [-A-Z0-9a-z] but the recommended set is actually: [_A-Z0-9a-z].
manykwh has quit [Client Quit]
<pjb>
Also, {1,8} and {1,3} is a little low, we can use more, but some renaming might need to occur to store the file on some file systems (MS-DOS, or ISO-9660 = CD-ROM).
manykwh has joined #commonlisp
<Spawns_Carpeting>
that seems like a fairly reasonable thing to do. i imagine a decent bit of things will choke if you start putting crazy stuff in pathnames
manykwh has quit [Client Quit]
<Spawns_Carpeting>
i do like how lisp represents pathnames in a way that is fairly platform independent with the pathname structure
manykwh has joined #commonlisp
karlosz has joined #commonlisp
manykwh has quit [Client Quit]
manykwh has joined #commonlisp
<pjb>
Spawns_Carpeting: but note that the pathname structure contains slots that are irrelevant for posix paths. eg. version or device. (but device can be mapped to c: on ms-dos path for example, and versions could be mapped to file extensions such as .~42~
<pjb>
)
<pjb>
Also, note how you may use the logical pathname translations, to map logical pathnames to implementation specific physical pathnames to deal with those variations.
karlosz has quit [Ping timeout: 244 seconds]
<pjb>
But make sure to note that logical pathanmes --> physical pathname <--> namestring --> path (and only partially namestring <-- path depending on the bytes in the path and the coding system used).
<pjb>
So if you use operators such as DIRECTORY you will only go back safely to physical pathname, not to logical pathname. (even if you may (directory "SOME:LOGICAL;PATHNAME;*.*"))
<pjb>
In any case directory returns a list of TRUENAME.
<pjb>
Also, note that this means on most implementations that the symbolic links are traversed. So (directory "/foo/*") -> (#P"/foo/bar" #P"/quux/boz") is possible, if there's in foo a symlink to /quux/boz.
shka has quit [Ping timeout: 240 seconds]
<Spawns_Carpeting>
pjb: do you prefer CL to scheme? i am curious how some people feel about the topic but I also don't want to start a flamewar or whatever. I tend to have a hard time deciding on which one I want to use
<Spawns_Carpeting>
im also going to have to figure out what a truename is, i read about namestring but I have not heard of truename
<White_Flame>
truename is the canonical filename on the filesystem
<White_Flame>
IMO CL is more practical, Scheme is intended to be more minimal
<Spawns_Carpeting>
thank you, that makes sense considering the name
<Spawns_Carpeting>
White_Flame: that is roughly how I feel about it right now as well. especially since SBCL exists which gives us a very high quality, high performance free/libre implementation
<Spawns_Carpeting>
SBCL is pretty nifty for sure
<White_Flame>
it's technically not free/libre, but public domain
<Spawns_Carpeting>
i didn't realize that is was public domain
<White_Flame>
well, truename is a "filename" as in #P"/home/me/foo.txt", where many equivalent pathnames can also refer to that (via relative names, etc)
dra has quit [Ping timeout: 258 seconds]
pve has quit [Quit: leaving]
trocado has joined #commonlisp
<Spawns_Carpeting>
whats up with SBCL using source forge by the way?
<Alfr>
White_Flame, hm ... I don't think truename does return a canonical path.
<Spawns_Carpeting>
a quick bit of research seems to show that source forge has replaced downloads on projects pages with malware
<Guest74>
sourceforge did that all themselves eh"
<Alfr>
White_Flame, given a file A, then after "ln A B", I doubt that (truename #P"A") will equal (truename #P"B").
ebrasca has joined #commonlisp
karlosz has joined #commonlisp
beach` has joined #commonlisp
karlosz_ has joined #commonlisp
karlosz has quit [Ping timeout: 258 seconds]
karlosz_ is now known as karlosz
<kakuhen>
Spawns_Carpeting: sourceforge is not the first, nor the last, project hosting service to become compromised
beach has quit [Ping timeout: 260 seconds]
<kakuhen>
In any case, if you do not trust the release binaries of SBCL, then you'll be glad to know SBCL is a Sanely Bootstrappable Common Lisp ;)
<White_Flame>
Alfr: hard links are below the level of filenames, though
<White_Flame>
we don't get to see inodes :-P
<White_Flame>
if the given path leads to a file, it will give the canonical pathname of that found filename entry