freenode/#lisp - IRC Chatlog
Search
16:09:18
pjb
ym: that's because, as I've said, there has been and still is a lot of changes in the graphic and UI technologies.
16:11:51
pjb
Also, you'd have to choose a platform for it. (asuming you cannot write versions for all the platforms). A lot of lispers use macOS. Another big share use linux.
16:12:27
pjb
More of them use emacs. Perhaps this would be the right choice of a platform for such tools.
16:16:56
ym
Well, I don't get this software "evolution" tendency either. I thought that layers of abstraction should hide implementation details and provide simple interface. Like 20 years ago I was able to write SCREEN 12 CRICLE (320, 240), 32 in QBasic to ouput a circle. And now I have to struggle with X protocol, CLX, write over 20 SLOC to make the same.
16:30:13
gendl
Hi, what different conditions or parameter settings can cause (format nil "~t" some-variable) to give different amounts of spacing?
16:31:37
gendl
I think wrapping (with-standard-io-syntax ...) around it will make it work the same in both cases I'm seeing. But without with-standard-io-syntax, the ~t seems to be generating different amounts of whitespace.
16:33:35
pjb
ym: you're right but in the case of UI, there are yearly fads, it's not software, it's fashion.
16:34:40
gendl
phoe: I'll try. I'm just looking at static customer code right now, without the ability to run it in their environment...
16:35:04
pjb
ym: strugglying with X11 would be nothing (and very dated!) Nowadays, you'd have to do this in 3D with OpenGL, etc…
16:37:48
ym
Oh, no. OpenGL is way more horrible thing in this perspective. There is known reason why CS/IT stuff getting worse, but that's off-topic.
16:50:01
gendl
Ok i have an example which shows different output with & without with-standard-io-syntax
16:51:55
gendl
So when I wrap this with w-s-io-s, the output has more whitespace (I can post the actual output if that helps)
16:57:57
phoe
gendl: can you give me the result of (list *print-lines* *print-miser-width* *print-pprint-dispatch* *print-right-margin* *print-level* *print-length* *print-lines* *print-circle* *print-escape* *print-pretty*) ?
16:58:47
pjb
gendl: on the other hand, you have newlines and tabs in your format strings. The newlines are ok but you may prefer explicit ~%. The tabs are bad since they're so implementation dependent.
16:59:42
gendl
looks like *print-pretty* is different, and the *print-pprint-dispatch* is different.
17:00:42
pjb
gendl: In general, I would avoid with-standard-io-syntax. Instead, I would define my own macro setting all the variables as I want them.
17:01:25
gendl
customer is running ANSI mode, I happen to be running modern-mode here (probably bad, I know)
17:03:10
gendl
The customer is comparing output from our previous version which was Allegro CL 9 (32-bit), vs. our new version they're trying to get into production, which is Allegro 10.1 (64-bit).
17:04:16
gendl
phoe: In my function `try' there is a lot of whitespace to the left of all but the first line.
17:04:49
gendl
Should the ~1t force it into column 1, even with all the leading whitespace in the format string?
17:06:26
gendl
But you're right, that doesn't look right. The ======... should obviously be just below the title.
17:07:21
gendl
pjb: It's not a matter of what I want -- this is customer code, i have no control over it. (I can make recommendations to them, though).
17:08:00
phoe
If the behavior of that code changed between different versions of Allegro CL, then I'd ask Franz for clarification.
17:09:36
pjb
gendl: the principle of software is that it should be soft and easily (cheaply) modifiable.
17:10:23
gendl
phoe: Before I go blaming Franz I have to make sure we didn't inadvertently change *print-miser-width* or *print-pretty* in our stuff.
17:10:25
pjb
gendl: otherwise, I would write the code to format tables from raw data and headers, without pre-conceived format. The format would be computed automatically from the data.
17:11:35
pjb
gendl: notice in my example, that you only have 2 formats: ~A for strings, which should not depend on *print- vars, and ~6,3f. If you get your 6 characters, then this format should not depend on the other *print- variables either.
17:12:32
phoe
...and if this is code written by the customer, make a shameless suggestion to them to patch it.
17:16:57
pjb
gendl: since you only have absolute ~T directive, preceded only by literal strings (and absolute ~T directives), (apart for the ~F and ~A that are trivial), then I would say that if you get bad results, it's a bug in the implementation.
17:18:53
gendl
*print-pretty* is supposed to be nil by default, right? I'm noticing in Allegro CL 10.1, *print-pretty* is t, out of the starting gate.
17:19:14
gendl
And the difference between having it t and nil is causing the differences which the customer is reporting.
17:22:25
phoe
The default values for *print-miser-width* and *print-pretty* are implementation-dependent.
17:24:26
gendl
But if you look at the actual documentation for *print-pretty* and *print-miser-width*, they both do say the initial value is implementation-dependent.
17:25:41
trittweiler
there are more instances where that's the case. The initial readtable versus (copy-readtable nil), perhaps. (Haven't checked)
17:26:02
gendl
So 'standard' is what you get with with-standard-io-syntax, but any given vendor can ship an image with non-standard initial values. Got it.
17:46:50
gendl
Disclaimer: it looks like those *print-pretty* and *print-miser-width* might not have changed between Allegro 9 and Allegro 10. I don't want to give wrong information here.
17:47:54
gendl
I have to sort out a few things to confirm (I don't have my Allegro 9 handy here) but it looks like (list *print-pretty* *print-miser-width*) have been (t 40) all along, in Allegro.
19:15:36
pjb
gendl: sorry, :center was wrong. Here's the correction: https://lpaste.net/4162159592878374912
21:21:57
housel
ebrasca: Internetworking with TCP/IP Volume One (and Volume Two) by Douglas E. Comer
21:27:30
no-defun-allowed
I still think there's a few edge cases and stuff that need cleaning up but I'm mostly there.
21:28:10
no-defun-allowed
For example, I forgot to respond with "ok ~a" if the versions are equal, which isn't an error but we ignore the "new" version
21:31:08
pjb
AeroNotix: the only choice you have, is whether you want the singularity to occur with CL or with python?
21:33:10
AeroNotix
I really hate to sound rude but I really get the feeling you're misunderstanding how hard reliably distributing state, consistency and networking issues can be
21:34:54
AeroNotix
This takes out a lot of the setup/teardown and writing of the actual distributed issues you will see and essentially you will receive just "your code breaks assumptions, xyz, during operations jki"
21:35:12
fouric
AeroNotix: i might be wrong, but it doesn't look like cl-decentralize actually handles synchronization? it looks like it's just allowing for message-sending
21:36:07
no-defun-allowed
When it finds a new node it asks it for any new messages it has, and compares it to its own.
21:37:12
AeroNotix
Personally, I find CL would be the perfect language for distributed programming but there are not many genuinely good libraries and some contracts/guarantees are very difficult to implement.
21:37:36
no-defun-allowed
cl-decentralise doesn't do any verification or storage of its own, but it can be done trivially. See example.lisp.
21:39:23
AeroNotix
aeth: I'm talking in general of certain kinds of distributed models of programming
21:39:41
no-defun-allowed
Well, I had a project which used a simple interpreter which read distributed files to verify data
21:40:16
AeroNotix
aeth: oh, btw, I didn't mean difficult to implement *in CL*. I just meant in general
21:40:20
no-defun-allowed
Then I decided it was too big and messy so cl-decentralise was attempt at writing a distributing layer which was as small and as simple as possible
21:41:05
AeroNotix
no-defun-allowed: I'm absolutely sure from reading it that it fails under many kinds of netsplits
21:41:48
AeroNotix
no-defun-allowed: though AS WELL, from the code, it looks as if a flavour of raft (et al) would be easily added on top, before reads/writes.
21:42:35
AeroNotix
because currently, under netsplits your code will accept writes on both sides of the split. Leading to bad inconsistencies. It doesn't matter about versions
21:42:58
AeroNotix
imagine a situation where you have clients reading from cl-distribute, and a collection of servers running cl-distribute serving as the client's datastore.
21:43:36
jmercouris
you don't need a consensus protocol, you need to distribute the information in a fault tolerant way across the network
21:44:05
jmercouris
and then you need some sort of topology you can overlay on-top of the network to handle failure
21:44:44
AeroNotix
I mention raft because without googling I am sure there will be a CL library for it
21:45:45
AeroNotix
wow, ok. I might've been wrong on that based on the 12 seconds of googling. Either way...
21:47:55
jmercouris
I guess that is not always an option, say for example, if you are running on a provider cloud
21:49:36
AeroNotix
no-defun-allowed: the point is, GETTING the data to the various servers in your network is like 1% of the problem.
21:50:11
AeroNotix
the other 99% is making sure you provide reliable consistency guarantees. What parts of the CAP theorum do you provide, etc.
21:50:14
jmercouris
I think if we operate on the model of a system without faults, it is a relatively easy problem
21:50:25
jmercouris
just a simple synchronization that can be achieved by running a sweep through the system
21:50:42
jmercouris
as soon as we introduce failure modes of any kind, then the problem becomes infinitely more complex and expensive
21:51:03
AeroNotix
I was running many distributed applications in AWS and I would experience a netsplit probably 1-2 a month
21:51:22
no-defun-allowed
You can put verification in stop-put-p which could handle, for example, ECDSA.
21:52:34
jmercouris
AeroNotix: maybe I should give it a try some day, though I'm quite satisfied with bare metal / digital ocean
21:53:03
AeroNotix
I've never lost a machine because of AWS' fuckup. I've lost three with DO. Anecdotal information but w/e
21:56:28
AeroNotix
I think the idea of a "decentralised lisp term database" is a great idea. Not sure if one exists.
21:57:16
jmercouris
I think what would be really cool would be an open source graph database implementation in lisp
21:58:56
AeroNotix
no-defun-allowed: I just meant a distributed database that stored arbitrary terms.
22:02:41
AeroNotix
you call a function with a serialized FD. The FD doesn't exist on the system being read- it fails.
22:03:10
White_Flame
huh, so you don't prevent the handle itself from serializing, you just assume its usage will break?
22:03:32
jmercouris
I guess you need to support two types of objects, a node object, and a vertex object
22:04:04
jmercouris
but of course the hard part is persistence of the graph database, loading it into memory, and searching it
22:07:25
jmercouris
stylewarning: this works for any kind of object? what about objects that contain objects?
22:08:13
stylewarning
jmercouris: Nested objects are fine. If *print-circle* is respected, then you'll even get proper references
22:10:11
stylewarning
jmercouris: CL-STORE also is pretty useful to know about (https://common-lisp.net/project/cl-store/)
22:10:33
jmercouris
I was just thinking aloud about what one would need to do to make a graph database using CLOS
22:11:01
jmercouris
maybe you could even build it on top of an RBDMS to serve as your persistence mechanism
22:14:18
jmercouris
unless maybe there is some ext that can give you a unique identity hash or something for each object
22:14:45
aeth
stylewarning: EQ only differs from EQL with numbers and characters. In pratice, you'd only see EQ potentially differ in a 64-bit implementation for double floats and bignums and maybe characters. Where do you use this?
22:15:09
stylewarning
aeth: I use it when I want to indicate to the reader of my program that I care about equality of reference.
22:19:47
stylewarning
jmercouris: actually, you can abuse your way to defining eq. For instance, (defun my-eq (x y) (let ((l (list y t))) (getf l x)))
22:23:01
aeth
stylewarning: Problem solved: (defun my-eq* (x y) (let ((l (list y t))) (declare (dynamic-extent l)) (getf l x)))
22:23:43
aeth
113 byte disassembly (and a call to getf) instead of 32 bytes (with no calls) in SBCL, though
1:49:09
AeroNotix
With #'push & #'pop. The documentation suggests that it takes a `place' but I am kind of inferring it means a `place' that evaluates to a list. Am I wrong?
1:50:31
Bike
i called it "list" because that's usual, but it would work just as well with any other value
1:50:43
Bike
the arguments and values section even says "place---a place, the value of which may be any object."
1:51:22
no-defun-allowed
eg (push 'thing (first my-stacks)) will push 'thing to the first item of my-stacks
1:52:08
AeroNotix
I just expect that `place' is anything that is setf-able. Not that `place' means that it is setf-able AND requires to be of a certain type
1:52:23
AeroNotix
Though: "push prepends item to the list that is stored in place, stores the resulting list in place, and returns the list."
1:52:41
Bike
pop imposes an additional requirement since it returns the CAR of the value of the place.
1:53:05
AeroNotix
Bike: "push prepends item to the list that is stored in place, stores the resulting list in place, and returns the list."
1:53:39
AeroNotix
I expect with `place' it is any http://www.lispworks.com/documentation/lw71/CLHS/Body/05_a.htm
1:54:30
Bike
don't take the description text too literally. the macroexpansion is the easiest way to understand it.
1:54:58
AeroNotix
How can it say: "place---a place, the value of which may be any object." but then "push prepends item to the list that is stored in place, stores the resulting list in place, and returns the list."
1:57:43
Bike
push has no reason to impose a restriction that the value of the place is a list, so it doesn't
1:58:36
AeroNotix
Really the reason I was looking at the docs so deeply when it said "place" is that I wanted to call a set of functions push/pop
2:00:09
Bike
At macroexpansion time, it doesn't know the type of the value of the place (what a mouthful)
2:02:05
Bike
setf works on information it has at macroexpansion time, stuff like the ltieral form of the place
2:02:27
Bike
for a customizable push, you couldn't take advantage except to do setf in the first place, so you'd have (push x y) expand into (setf y (push-function x y))
2:02:41
Bike
and then push-function could be generic or whatever, but then you're missing out on some stuff
2:31:18
pjb
AeroNotix: pop on a non-list would signal an error thru car. But push wouldn't: it would just create a dotted-list.
2:40:57
AeroNotix
pjb: sure, I see the behaviour, it was the documentation that seemed that there was something more to it
3:24:08
White_Flame
AeroNotix: if you have a history in C, you can think of a 'place' sort of like an lvar
3:24:52
White_Flame
it's a syntactic expression that shows where to store something, not specifically evaluated for its value
3:25:18
White_Flame
(setf (car foo) 3) doesn't evaluate (car foo) and return its place, the shape of (car <parameter>) indicates where it's to be stored
3:26:18
White_Flame
(hmm, I'm wondering if I remember the term 'lvar' correctly. But basically whatever's to the left of the equals sign in C)
3:26:43
Bike
yeah, the main difference between lvalues and places in my mind is that i can understand places
3:28:00
White_Flame
I'm getting too long out of that world to be fully confident in specific analogies from it
3:28:45
Bike
i think the main problem with the analogy is that an lvalue is still a value, which a place doesn't have to correspond to (e.g. multiple values), but that's not a huge deal
3:29:46
White_Flame
AeroNotix: also, have fun reading up on locatives. They're sort of a parallel to pointers, as in it's a reference to a slot you can dereference & store
3:50:34
loke
pjb: is cll actually useful anymore? I check there once in a while and there are like 3 people posting there (if you exclude wj :-) )
3:51:13
pjb
loke: it's asynchronous, and you can include lots of code in a single message. So it would be more efficient than irc for a lot of stuff we do here…
3:53:18
pjb
(setf (car foo) 3) can expand to (let ((val 3)) (rplaca foo val) val) in ccl: (macroexpand-1 '(setf (car foo) 3)) #| --> (ccl::set-car foo 3) ; t |#
3:53:35
loke
sthalik: Also note that CL's maths spec is more thorough than C's. For example, it defines complex results for trignometric operations and also support rationals.
3:54:24
loke
pjb: Well sure, I don't disagree with you there. But all the ability to type long messages aren't work much if there is no one read them. :-(
3:54:39
aeth
sthalik: I'm not sure if there's a copysign, but there's a signum, so you don't really need copysign
3:56:50
sthalik
aeth, can you paste the disassembly when specialized for float with speed no debug/safety+no prologue please?
3:58:55
aeth
It looks like the version of SBCL I'm using doesn't optimize signum for single-float (i.e. it calls the function, even though there's probably a simpler way)