interruptinuse has quit [Quit: ZNC - https://znc.in -- bye bye!]
interruptinuse has joined #lisp
drainful has joined #lisp
Volt_ has quit [Remote host closed the connection]
koenig has quit [Ping timeout: 252 seconds]
frgo has joined #lisp
koenig has joined #lisp
nicko has joined #lisp
vydd has joined #lisp
Fare has quit [Ping timeout: 240 seconds]
quazimodo has quit [Read error: Connection reset by peer]
quazimodo has joined #lisp
clothespin_ has joined #lisp
<aeth>
I think it goes LISP 3.1 -> LISP 95 -> LISP 98 -> LISP Me -> LISP XP -> LISP Vista -> LISP 7 -> LISP 8 -> LISP 10
brettgilio has joined #lisp
Fare has joined #lisp
<ebrasca>
aeth: Are you sure about it?
EvW1 has joined #lisp
dddddd has quit [Remote host closed the connection]
EvW has quit [Ping timeout: 260 seconds]
EvW1 is now known as EvW
zaquest has quit [Ping timeout: 260 seconds]
zaquest has joined #lisp
xkapastel has quit [Quit: Connection closed for inactivity]
Josh_2 has joined #lisp
nullniverse has joined #lisp
nullniverse has quit [Changing host]
nullniverse has joined #lisp
ahungry has joined #lisp
EvW has quit [Ping timeout: 240 seconds]
space_otter has joined #lisp
<Josh_2>
In CLOS encapsulation only occurs with data right?
fortitude has quit [Ping timeout: 260 seconds]
shifty has joined #lisp
whiteline has quit [Read error: Connection reset by peer]
whiteline has joined #lisp
vidak` has quit [Quit: because it is my desire]
wsinatra has joined #lisp
shunter has quit [Remote host closed the connection]
karlosz has quit [Quit: karlosz]
quazimodo has quit [Ping timeout: 265 seconds]
orivej has joined #lisp
* no-defun-allowed
is still waiting for LISP 2
<jcowan>
There were many Lisp 1.6s, actually, roughly one per university
<aeth>
The alternative to the version scheme I proposed involves having a LISP Server 2003 so I hope it goes with the sequence I proposed
akoana has left #lisp ["Leaving"]
<aeth>
Josh_2: I'm probably a bit rusty with my OOP concepts but the way I'd describe 'encapsulation' in CLOS is (1) only access through accessors not through slot access and (2) give the slots a different name from the accessors and (3) do not export the slot names (only the accessor names)
<aeth>
Josh_2: So e.g. (%foobar :accessor foobar :initarg :foobar :initform 42) and only export foobar, and that's encapsulation
<aeth>
So slots are encapsulated, but only if you enforce access to be through accessors via naming
<aeth>
Really, I'd say that you can only really encapsulate symbols. Probably a bit controversial.
<Josh_2>
Okay thanks aeth :) I thought that was the case
haziz has joined #lisp
smokeink has joined #lisp
<aeth>
It's the only place where you see a private/public distinction that's not a convention, anyway. Well, unless you count closures as encapsulation.
haziz has quit [Client Quit]
<Josh_2>
well someone I was talking to, was saying that CLOS isn't real OO because it doesn't have encapsulation, and then said that it is because you can use :export with defpackage
<aeth>
I mean, you can export a %foo and you can do your-package::%foo so there is some degree of convention no matter what, yes
<aeth>
but at some point, either you have escape hatches or you make unit testing pretty hard
anewuser has joined #lisp
whiteline has quit [Ping timeout: 260 seconds]
ebrasca has quit [Remote host closed the connection]
<ahungry>
I personally dislike private methods in OOP in more java-based languages (I would always rather there be solid unit coverage)
<beach>
Good morning everyone!
smokeink has quit [Ping timeout: 258 seconds]
<ahungry>
morning
smokeink has joined #lisp
<aeth>
Some languages permit you to do things that you should normally never do and that would instantly fail any code review if used in regular code, like accessing clearly private (% prefixed, never exported from the package, etc.) slots. I guess the advantage is you don't need to rely on the debugger to get that information.
nullniverse has quit [Quit: Leaving]
<aeth>
I guess it's a bit unfortunate that because of the dynamic and image based nature of the language you can't optimize away private things since anyone could add code at runtime involving foo::%secret-symbol and use with-slots on it, though.
<beach>
It is usually "just" a matter of making the system implementer work harder. We are very lucky in that we (as opposed to separately compiled languages) have full access to the entire code base at any point in time, and that the standard requires the compiler to be present.
nicko has quit [Remote host closed the connection]
enrioog has joined #lisp
enrioog has quit [Read error: Connection reset by peer]
<beach>
It is true that the creators of the Common Lisp standard did not make life easy for the implementer, but I think that's the right choice if it gives more convenience to the application developer. After all, there are many more applications written (or there ought to be) than Common Lisp systems to implement.
enrio has quit [Ping timeout: 268 seconds]
madrik has quit [Ping timeout: 260 seconds]
Necktwi has quit [Ping timeout: 268 seconds]
_whitelogger has joined #lisp
quazimodo has joined #lisp
Fare has quit [Ping timeout: 260 seconds]
wsinatra has quit [Quit: WeeChat 2.7]
<jcowan>
If you want privacy, put things inside closures. There can't be anything more private than that.
<beach>
The quest is silly though. If you can't trust yourself or your colleagues to avoid touching data that will break the application, you won't get much done.
<ahungry>
yup
<beach>
Such protection is the domain of the operating system.
pjb has joined #lisp
quazimodo has quit [Ping timeout: 260 seconds]
<beach>
In C++ you can do #define private public, or you can run the application from the debugger and alter any memory location.
Kevslinger has quit [Quit: Connection closed for inactivity]
Fare has joined #lisp
vidak` has joined #lisp
_whitelogger has joined #lisp
Fare has quit [Ping timeout: 260 seconds]
bacterio has joined #lisp
bacterio has quit [Client Quit]
bacterio has joined #lisp
bacterio has quit [Changing host]
bacterio has joined #lisp
<White_Flame>
and top popular langauges JS and Python just use naming convention for internals, like some lisps do with % prefixing anyway
Arcaelyx has quit [Read error: Connection reset by peer]
Arcaelyx has joined #lisp
Fare has joined #lisp
vlatkoB has joined #lisp
anewuser has quit [Quit: anewuser]
ggole has joined #lisp
ahungry has quit [Remote host closed the connection]
Fare has quit [Ping timeout: 260 seconds]
ryukinix has joined #lisp
ryukinix has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 265 seconds]
shifty has quit [Ping timeout: 265 seconds]
terpri has quit [Remote host closed the connection]
terpri has joined #lisp
terpri has quit [Remote host closed the connection]
terpri has joined #lisp
terpri has quit [Remote host closed the connection]
terpri has joined #lisp
cmatei has quit [Quit: Leaving]
cmatei has joined #lisp
terpri has quit [Remote host closed the connection]
terpri has joined #lisp
terpri has quit [Remote host closed the connection]
libertyprime has joined #lisp
terpri has joined #lisp
terpri has quit [Remote host closed the connection]
terpri has joined #lisp
<p_l>
White_Flame: Python does because of rather bad reasons, it's not a good idea to use it for one's justification
<White_Flame>
yep, just saying that it's a well-accepted idiom, regardless of the particulars of the definition of OO
Arcaelyx has quit [Ping timeout: 268 seconds]
<p_l>
White_Flame: well, in Python's case, it's more that they wanted to have inaccessible "private" members in class but didn't manage to implement classes in the first place...
marusich has joined #lisp
gravicappa has quit [Ping timeout: 268 seconds]
davr0s_ has quit [Ping timeout: 246 seconds]
johnjay has quit [Read error: Connection reset by peer]
johnjay has joined #lisp
shka_ has joined #lisp
scymtym_ has quit [Ping timeout: 248 seconds]
scymtym_ has joined #lisp
decent-username has joined #lisp
smokeink has quit [Quit: Leaving]
sauvin has joined #lisp
_whitelogger has joined #lisp
ebzzry has quit [Ping timeout: 258 seconds]
william1 has joined #lisp
hhdave has joined #lisp
ebzzry has joined #lisp
megalography1 has quit [Ping timeout: 248 seconds]
hhdave has quit [Ping timeout: 268 seconds]
vidak` has quit [Remote host closed the connection]
kajo has quit [Ping timeout: 260 seconds]
pnp has joined #lisp
space_otter has quit [Remote host closed the connection]
__vlgvrs has joined #lisp
mathrick has quit [Remote host closed the connection]
megalography has joined #lisp
william1 has quit [Ping timeout: 258 seconds]
_paul0 has quit [Ping timeout: 248 seconds]
mathrick has joined #lisp
shka_ has quit [Quit: Konversation terminated!]
luna_is_here_ has joined #lisp
william1 has joined #lisp
ebzzry has quit [Ping timeout: 268 seconds]
william1 has quit [Ping timeout: 260 seconds]
ba has joined #lisp
je4i has joined #lisp
rippa has joined #lisp
khisanth_ has quit [Ping timeout: 258 seconds]
ba has left #lisp [#lisp]
nowhere_man has quit [Remote host closed the connection]
je4i has quit [Client Quit]
ebrasca has joined #lisp
whiteline has joined #lisp
whiteline has quit [Ping timeout: 265 seconds]
khisanth_ has joined #lisp
william1 has joined #lisp
orivej has joined #lisp
william1 has quit [Ping timeout: 268 seconds]
libertyprime has quit [Ping timeout: 258 seconds]
pjb has quit [Remote host closed the connection]
xvx has joined #lisp
pjb has joined #lisp
william1 has joined #lisp
pilne has quit [Quit: East bound and down, loaded up and truckin']
insilications has joined #lisp
SlashLife has joined #lisp
quazimodo has joined #lisp
jonatack has quit [Ping timeout: 248 seconds]
atgreen_ has joined #lisp
insilications has quit [Quit: Leaving]
insilications has joined #lisp
pnp has left #lisp [#lisp]
varjag has joined #lisp
quazimodo has quit [Ping timeout: 265 seconds]
cosimone has joined #lisp
marusich has quit [Remote host closed the connection]
quazimodo has joined #lisp
pjb has quit [Read error: Connection reset by peer]
kensanata has quit [Ping timeout: 240 seconds]
pjb has joined #lisp
troydm has quit [Ping timeout: 252 seconds]
jeosol has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 265 seconds]
__vlgvrs has quit [Ping timeout: 252 seconds]
ebzzry has joined #lisp
troydm has joined #lisp
insilications has quit [Quit: Leaving]
william1 has quit [Ping timeout: 260 seconds]
_whitelogger has joined #lisp
nowhere_man has joined #lisp
cosimone has quit [Quit: Quit.]
troydm has quit [Ping timeout: 260 seconds]
amerlyq has quit [Quit: amerlyq]
troydm has joined #lisp
Necktwi has joined #lisp
jmercouris has joined #lisp
Vodyanoy has joined #lisp
Lycurgus has joined #lisp
dale has quit [Quit: My computer has gone to sleep]
clothespin_ has quit [Ping timeout: 265 seconds]
raghavgururajan has joined #lisp
ebrasca has joined #lisp
jonatack has joined #lisp
Lycurgus has quit [Quit: Exeunt]
ebzzry has quit [Read error: Connection reset by peer]
ebzzry has joined #lisp
amerlyq has joined #lisp
Vodyanoy has quit [Quit: Leaving]
vaporatorius has quit [Ping timeout: 265 seconds]
frgo has quit [Read error: Connection reset by peer]
frgo has joined #lisp
Posterdati has quit [Ping timeout: 252 seconds]
tryhard21 has joined #lisp
whiteline has joined #lisp
wsinatra has joined #lisp
gravicappa has joined #lisp
jmercouris has quit [Ping timeout: 258 seconds]
milanj has joined #lisp
EvW1 has joined #lisp
Posterdati has joined #lisp
Arcaelyx has joined #lisp
fookara has joined #lisp
vaporatorius has joined #lisp
vaporatorius has quit [Changing host]
vaporatorius has joined #lisp
luna_is_here_ has quit [Ping timeout: 265 seconds]
__jrjsmrtn__ has quit [Ping timeout: 268 seconds]
__jrjsmrtn__ has joined #lisp
doublex_ has quit [Read error: Connection reset by peer]
doublex_ has joined #lisp
atgreen_ has quit [Ping timeout: 265 seconds]
EvW1 has quit [Ping timeout: 248 seconds]
doublex_ has quit [Read error: Connection reset by peer]
doublex_ has joined #lisp
jonatack has quit [Ping timeout: 258 seconds]
efm has joined #lisp
jonatack has joined #lisp
amerlyq has quit [Ping timeout: 268 seconds]
cosimone has joined #lisp
ebrasca has quit [Ping timeout: 240 seconds]
jonatack has quit [Ping timeout: 265 seconds]
ebrasca has joined #lisp
cosimone has quit [Remote host closed the connection]
cosimone has joined #lisp
xvx has quit [Quit: xvx]
bendersteed has quit [Quit: bye]
cosimone has quit [Remote host closed the connection]
cosimone has joined #lisp
<phoe>
I have a CLOS design question.
<phoe>
I would like to create a function that parses a string and returns an object of some sort.
<pjb>
So far, so good.
<phoe>
I want to be able to extend this function, preferably by writing methods on it.
amerlyq has joined #lisp
<pjb>
Extend it how? Since it will always take a string as parameter… There will be only a single (main) method.
<phoe>
I have a string and a list of sub-functions that are called on this object - and either they accept it and return some object (which is returned from the original function), or they decline and return NIL, and the next sub-function is called in order.
<pjb>
So you have post-processing filter functions?
<phoe>
Not really post-processing - they are the actual matchers.
<pjb>
The parsing and original object will always be the same, you don't want to extend this?
<phoe>
I'm doing some sorta pattern matching here, and I want to call the matchers until one of them goes "hey, I accept this input!".
<phoe>
I could do this by having a list of lambdas and looping over it until one of these lambdas returns true.
<phoe>
I'm looking for a more CLOSy way of achieving this though.
<pjb>
So it's not a CLOS question, but a parser question?
<phoe>
Kinda-yes-kinda-no. I know how to achieve this behaviour in a CLOSless manner, but I'm looking for a way to represent this using GFs and methods.
<pjb>
This is exactly how parser combinators work.
<pjb>
Again, there's no dispatching involved, so no generic function.
<phoe>
Is it? I don't want to combine things; this is literally a big COND that I would like to be able to extend in some way.
<MichaelRaskin>
Even close to a big OR
<phoe>
Sure, OR will work as well.
<pjb>
Unless, you go crazy, transform the string (a vector of characters) into some kind of object graphs (eg. a list of tokens of different classes), and dispatch methods on those tokens or pairs of tokens…
amerlyq has quit [Quit: amerlyq]
<phoe>
That's the crazy way.
<phoe>
I don't want to go there.
<MichaelRaskin>
phoe: OR is usually a valid combinator for parsers
<MichaelRaskin>
I guess you could create a huge aount of :around methods?
dddddd has joined #lisp
<MichaelRaskin>
Or can there be only one
<phoe>
MichaelRaskin: the latter.
<pjb>
"program foo; begin writeln('hello'); end;" -> (#<program> #<identifier foo> #<semi> #<begin> #<identifier writeln> #<open> #<string 'hello'> #<close> #<semi> #<end> #<semi>) and then (defmethod named-program ((p program) (i identifier) (s semi)) …) …
<pjb>
but the problem is that parsing is done by groupping different numbers of tokens, ie. different number of disptching objects. This is no good…
<phoe>
MichaelRaskin: ...or I could write my own method for COMPUTE-APPLICABLE-METHODS that always returns *all* the methods I define. And use the :OR method combination.
<phoe>
pjb: you're going off-topic. This is not what I want to do.
<pjb>
phoe: what you want is parser combinators!
<pjb>
Not generic functions.
<pjb>
Forget about clos, you have a parsing problem here.
<MichaelRaskin>
pjb: just watch phoe express parser combinators inside CLOS I guess
<pjb>
ok. popcorn time.
<beach>
phoe: Your methods would still need different specializers. A standard generic function can not have two methods with the same specializers.
cosimone has quit [Remote host closed the connection]
cosimone has joined #lisp
<phoe>
beach: correct. One second, let me write up how I imagine it...
<beach>
phoe: But you can use a non-standard generic function, or a funcallable-standard-object.
<beach>
MichaelRaskin: "number" of things, "amount" of stuff.
jonatack has joined #lisp
<pfdietz>
It can have two methods with the same specializers, but they have to have different qualifiers.
baby_yo92 has joined #lisp
<beach>
Right, that.
<pfdietz>
In practice, this just means you hang on new superclasses and specialize the methods on those.
<beach>
Subclasses, you mean?
<pfdietz>
No, superclasses. If I want to have multiple methods on some class C, I just make it inherit from a new stub class C', and specialize on that.
<pfdietz>
And link things together with call-next-method or method combination
<pfdietz>
I commonly see this with :around methods, which nest together.
<pjb>
or define a new method combination that accept any number of chained methods.
anewuser has joined #lisp
vidak` has joined #lisp
earl-ducaine_ has joined #lisp
<phoe>
Hm. Is it possible for the programmer to write methods for COMPUTE-APPLICABLE-METHODS and have this influence the process of choosing the applicable methods for a GF?
baby_yo92 has quit [Quit: -a- IRC for Android 2.1.55]
<phoe>
I can't see it taking an effect in SBCL.
<pjb>
phoe: if you have a class of generic functions, or (eql #.(function my-gf)), why not.
baby_yoda_squadr has joined #lisp
<phoe>
pjb: I am using EQL, yes. And it seems that the method on C-A-M is *not* called when I call my GF.
<phoe>
Let me come up with a simpler case...
<pjb>
phoe: it might have been called earlier, and the result be cached.
<pjb>
Try adding a new method, so that it's called again?
<phoe>
pjb: nope, I just tried after FMAKUNBOUNDing the function altogether.
<phoe>
pjb: uhhhhh. Substitute STRING for MY-STRING or anything.
Fare has joined #lisp
<phoe>
That's not the part that I wanted to ask a question about.
<pjb>
Notice how it says, direct instances of standardized classes, not standardized classes. This forbids (eql …).
<pjb>
You will have to define your own class of generic functions.
<pjb>
and use (defgeneric … (:generic-function-class my-generic-function-class))
<phoe>
One second though. Direct instances of standardized classes.
<pjb>
then you can define a c-a-m dispatching on my-generic-function-class.
random-nick has joined #lisp
<phoe>
So the issue is actually in DEFMETHOD C-A-M.
<phoe>
I cannot do (defmethod compute-applicable-methods ((generic-function (eql #'read-set)) args) ...) since #'READ-SET is a direct instance of GENERIC-FUNCTION.
<pjb>
ccl signals an error when you try it. perhaps sbcl accepts the method silently, but the old one is always used.
<phoe>
I see. Well, it was worth a shot.
baby_yoda_squadr has quit [Ping timeout: 240 seconds]
<pjb>
anyways, your gf was read-thing, not read-set.
wxie has joined #lisp
<phoe>
uh, that second thing's hacky code that I didn't even evaluate because it didn't work earlier before.
baby_yoda_squadr has joined #lisp
<phoe>
Well. I thought that what I wanted would be somewhat easy to do in CLOS. Seems like I wasn't correct, hmm.
<phoe>
(define-method-combination chain ...) is what I was looking for.
<phoe>
mfiano: I remember you had this issue some time ago. Here's something that looks like a solution.
doublex_ has quit [Read error: Connection reset by peer]
doublex_ has joined #lisp
lavaflow has quit [Ping timeout: 265 seconds]
<phoe>
pjb: 11.1.2.1.2.19 doesn't fully make sense though.
<phoe>
See NO-NEXT-METHOD. Is (defmethod no-next-method ((gf (eql #'foo)) method &rest args) ...) valid Lisp?
<phoe>
clhs no-next-method states that "The generic function no-next-method is not intended to be called by programmers. Programmers may write methods for it." but it doesn't specify anything against 11.1.2.1.2.19.
<pjb>
You can always write methods, but on your own classes.
<earl-ducaine>
clisp apparently has a system/package, 'regexp' which is used by some utility files in in quicklisp systems, e.g. babel/scripts/release.lisp. Does anyone know if that regexp package corresponds to it's own system in quicklisp?
<Xach>
earl-ducaine: it doesn't.
earl-ducaine_ has quit [Ping timeout: 260 seconds]
<earl-ducaine>
Xach: Ah. ok. Thanks for the (negative) confirmation!
<Xach>
earl-ducaine: it is part of clisp only
<Xach>
earl-ducaine: what prompts the question?
<earl-ducaine>
Xach the semantics of its regular expression interface look to be very close to Emacs, which would help porting some Emacs code.
<Xach>
ah
<Xach>
earl-ducaine: I don't know for sure, but maybe they use the same C regular expression underneath.
<earl-ducaine>
Xach: with Emacs, it does appear that the kernel of their regexp handling is in C.
<Xach>
most of CLISP's built-in features are in C as well
<earl-ducaine>
Xach: Ultimately it's not that hard for me to adapt one of the standard cl regexp systems, I just wanted to make sure that it hadn't already been done.
earl-ducaine_ has joined #lisp
earl-ducaine_ has quit [Client Quit]
baby_yoda_squadr has joined #lisp
fanta1 has quit [Quit: fanta1]
sjl has quit [Quit: WeeChat 2.2-dev]
baby_yoda_squadr has quit [Quit: Leaving]
brettgilio has quit [Ping timeout: 260 seconds]
baby_yoda_squadr has joined #lisp
<baby_yoda_squadr>
hello
baby_yoda_squadr has left #lisp [#lisp]
nullniverse has quit [Remote host closed the connection]
baby_yoda_squadr has joined #lisp
baby_yoda_squadr has quit [Client Quit]
baby_yoda_squadr has joined #lisp
fanta1 has joined #lisp
<decent-username>
baby_yoda_squadr: Your name is almost as stupid as mine.
<decent-username>
Actually your name might even be worse. LOL
<baby_yoda_squadr>
lol
<baby_yoda_squadr>
good
fanta1 has quit [Client Quit]
<baby_yoda_squadr>
that's how i roll yo
efm has quit [Remote host closed the connection]
efm has joined #lisp
learning has quit [Remote host closed the connection]
baby_yo99 has joined #lisp
baby_yo99 has quit [Client Quit]
baby_yo73 has joined #lisp
baby_yo73 has quit [Client Quit]
<galdor>
following the discussion on package local nicknames, is there a good way to name systems to avoid collisions ? I'm thinking about quicklisp which has a single global namespace
<galdor>
is using something such as "com.example.foo" common ?
Lycurgus has joined #lisp
<pjb>
It's a good solution to avoid collision.
<Lycurgus>
_death why is bordeaux-threads not CL-quality or did I misread that?
baby_yoda_squadr has quit [Remote host closed the connection]
<Xach>
galdor: it is very uncommon
baby_yoda_squadr has joined #lisp
<Xach>
galdor: i think searching the internet for a package name before choosing a name is a way to avoid conflicts.
<Xach>
using a creative name helps. please don't call your library cl-<some generic task>!
<Xach>
if you can make a tortured pun that includes the letters "CL" that is a very good name
<galdor>
yeah cl-* is crowded
<galdor>
but I can't seem to find a downside to using a full domain
<galdor>
it's not like we have to type it (slime + helm does the job)
* Lycurgus
can't recall seeing a dot qualified pkg name
<MichaelRaskin>
hu.dwim !
<galdor>
and some informatimago stuff too
doublex_ has quit [Read error: Connection reset by peer]
doublex_ has joined #lisp
baby_yo17 has joined #lisp
baby_yo17 has quit [Client Quit]
<Xach>
com.gigamonkeys too.
<Lycurgus>
i suppose any threading pkg is best done by the implementation
<Xach>
it's not that it's never done, it's just rarely done and extremely ugly.
ggole has quit [Quit: Leaving]
baby_yoda_squadr has quit [Ping timeout: 258 seconds]
<Lycurgus>
well i was thinking dots to dash/hyphen would be the thing
baby_yoda_squadr has joined #lisp
<Lycurgus>
and maybe reversing
<pjb>
The only question, is what happens to tld.name when name.tld becomes unregistered or taken over by another entity than the author of the code…
<pjb>
I would expect renaming in such an occurence…
EvW1 has joined #lisp
brettgilio has joined #lisp
<Lycurgus>
i consider the suffixes transient
<Lycurgus>
for mine anyway
bitmapper has joined #lisp
<_death>
Lycurgus: bordeaux-threads api is quite good, but it's incomplete
milanj has quit [Quit: This computer has gone to sleep]
<galdor>
another solution would be to have support for namespaces in quicklisp; user/system would do the trick
<Xach>
galdor: quicklisp is a system for downloading software automatically. it isn't a requirement and i don't think naming solutions should be designed with quicklisp in mind.
<Xach>
plenty of people don't use it and they should benefit from good ideas too
<galdor>
in a way it makes sense
<Lycurgus>
how would that affect running lisp?
<galdor>
but I have the feeling that evolving the way systems are named would be really hard
<MichaelRaskin>
user/system stuff has quite a few problems
<MichaelRaskin>
Consider the fact that sharplispers exist
<galdor>
and to be honest in practice it's only a problem with quicklisp: if you manage your dependencies yourself, you really do not care because you choose what you have
<galdor>
while with quicklisp, if a name is taken, there's nothing you can do
<galdor>
it is one of the rare things I like with go, the absolute reference for packages
<MichaelRaskin>
Unversioned absolute references
<MichaelRaskin>
Approximately the exact worst way to do references
<phoe>
we have package-local nicknames though
<MichaelRaskin>
Projects do change primary locations…
<phoe>
what about conflict in the system namespace
<phoe>
ASDF might suffer from the same problem
<MichaelRaskin>
Technically, with PLN we could do a level-above, I guess
<galdor>
yes and it's a pain, but it means there is no conflict because I can reference a particular fork of a project
<galdor>
if a project has issues on quicklisp, it does not matter that a fork fixes them, you get what's on quicklisp
<MichaelRaskin>
Well, you can run your own dist, in _addition_ to Quicklisp
<MichaelRaskin>
Or just checkout to local-projects
<Xach>
local-projects (or asdf search in general) is the escape hatch from unsuitable quicklisp systems
<galdor>
local projects only work if you're alone and have a single machine; of course you can still version a repository with all local projects and share it
<galdor>
but then if you do that, why using quicklisp
<galdor>
it's still better than nothing, and it works :)
<Lycurgus>
there's no ql which updates the local pkgs as opposed to ql itself, is that right?
<Lycurgus>
*ql:<whatever>
brettgilio has quit [Quit: Quit]
learning has joined #lisp
<phoe>
Lycurgus: it's called cd ~/quicklisp/local-projects/foo && git pull
<Lycurgus>
k
<phoe>
or rather, there are scripts that automatically call git pull on each folder in a repo
brettgilio has joined #lisp
<Lycurgus>
scripts distributed with ql?
<Lycurgus>
or made ad hoc?
<phoe>
the latter
<Lycurgus>
ah
<phoe>
stackoverflow has some
<Lycurgus>
it would be nice to have Xach's imprimatur
<phoe>
quicklisp has no idea how to update local projects though
<Lycurgus>
right, got it
<phoe>
they can be versioned in git, hg, darcs, or in D:\Lisp\Projects\old_versions\
<phoe>
quicklisp only manages and is able to update the projects that are available in dists; for local-projects, quicklisp says, "this is your folder, you manage it yourself"
<Lycurgus>
so nuke and rebuild should work igess
slyrus__ has joined #lisp
slyrus_ has quit [Ping timeout: 268 seconds]
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
Lycurgus has quit [Quit: Exeunt]
slyrus_ has joined #lisp
prumnopytis has joined #lisp
slyrus__ has quit [Ping timeout: 268 seconds]
gravicappa has quit [Ping timeout: 268 seconds]
learning has quit [Remote host closed the connection]
ealfonso has joined #lisp
gravicappa has joined #lisp
milanj has joined #lisp
EvW1 has quit [Ping timeout: 248 seconds]
enrio has quit [Ping timeout: 240 seconds]
doublex_ has quit [Read error: Connection reset by peer]
doublex_ has joined #lisp
Fare has joined #lisp
learning has joined #lisp
enrio has joined #lisp
slyrus__ has joined #lisp
learning has quit [Remote host closed the connection]
scymtym_ has quit [Ping timeout: 245 seconds]
scymtym__ has joined #lisp
slyrus_ has quit [Ping timeout: 265 seconds]
learning has joined #lisp
learning has quit [Client Quit]
terpri has quit [Remote host closed the connection]