Advent of Code starts soon

[pixel...@gmail.com]

Don't know if anyone has done Advent of Code ...
The year before last I solved one of the days using Medley but I didn't save my answers.

Essentially, they're programming puzzles (12 this year) with a daily puzzle of two parts.

There are 12 days this year rather than 25. (They get harder towards the end).
Quite a lot of them are best served by languages with heavy collection processing facilities as well as heavy text manipulation facilities. Might be harder with Medley as we could use a regex library.

https://adventofcode.com/

[Paolo Amoroso]

The schedule is abit too tight for a slow coder and thinker like me, even with 12 days instead of 25, and I'm not into puzzles. So I'll have to decline.

--
You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lispcore/64bfdff1-b1e6-466c-860e-42a7b14dfcbdn%40googlegroups.com.

--

Paolo Amoroso | Blog | Mastodon

[Paolo Amoroso]

Vindarel is doing Advent of Code in Common Lisp.

On Mon, Dec 1, 2025 at 5:34 AM pixel...@gmail.com <pixel...@gmail.com> wrote:

--
You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lispcore/64bfdff1-b1e6-466c-860e-42a7b14dfcbdn%40googlegroups.com.

[pixel...@gmail.com]

Lisp is pretty well suited in general for quite a few of these.
I used Emacs Lisp last year which has a great deal of power thanks to many of CL's utilities being ported some time ago.
Emacs Lisp now has traces of Common Lisp, Scheme, and Clojure if you know where to look.

In the end I think I'll just use Common Lisp do a few and call it good.
I was thinking about doing it in Medley yesterday for more visibility to the Project but I think I need to do a few quickly then move on to something more interesting.
I was going to do it in the CL implementation we've got, but the into clause in LOOP is missing. (But I'm happy we have a mostly compliant LOOP now)

Still I'm sure it can be done in InterLisp. :)
I'm going to take a break from the public facing Interlisp stuff for a while.

[pixel...@gmail.com]

I lied! 

Day 2 done in Medley (yes, Common Lisp used).

Each person's data set is unique to their login so it's not cheating to show you my answers.
I did a CL:COMPILE-FILE and it still took quite a bit of time but an answer was produced. (SBCL blows through it instantly).
But that's fine, I still like Medley having CL as an option.

[Paolo Amoroso]

Great job. How long did it take? Tens of seconds? Minutes?

To view this discussion visit https://groups.google.com/d/msgid/lispcore/81112207-1d79-496a-ae1d-8f56ba3af0c8n%40googlegroups.com.

[Nick Briggs]

Cool.  Did you load the DFASL it produced?  Unless you give it one of the other keyword arguments (perhaps :LOAD T) CL:COMPILE-FILE just compiles it to produce the DFASL  but does not load it back into the system, so you would have still been running interpreted.

[pixel...@gmail.com]

I think so...

I was using FILESLOAD after each compilation (I thought it loads the DFASL updating the function to the compiled form until edited.).
I tried it with just LOAD T as suggested. 
I'll include the Lisp file as well (I guess if anyone wants to try the puzzle for Day 2 themselves don't spoil it with my code. :P)

[pixel...@gmail.com]

Ah, here is the source if you'd also like to try it in other implementations.
Forgot to include it. (Though I'm not complaining about Medley)

[pixel...@gmail.com]

Strange, I thought I selected from my desktop. Let me try once more...

[Matt Heffron]

By default FILESLOAD will not load a file that has been loaded before, unless given the LOADFROM “option”.

See IRM 17.1

 

From: lisp...@googlegroups.com <lisp...@googlegroups.com> On Behalf Of pixel...@gmail.com
Sent: Tuesday, December 2, 2025 10:26 AM
To: Medley Interlisp core <lisp...@googlegroups.com>
Subject: Re: Advent of Code starts soon

 

I think so...

I was using FILESLOAD after each compilation (I thought it loads the DFASL updating the function to the compiled form until edited.).
I tried it with just LOAD T as suggested. 
I'll include the Lisp file as well (I guess if anyone wants to try the puzzle for Day 2 themselves don't spoil it with my code. :P)

On Tuesday, December 2, 2025 at 10:09:42 AM UTC-7 nicholas...@gmail.com wrote:

Cool.  Did you load the DFASL it produced?  Unless you give it one of the other keyword arguments (perhaps :LOAD T) CL:COMPILE-FILE just compiles it to produce the DFASL  but does not load it back into the system, so you would have still been running interpreted.

 

On Dec 2, 2025, at 00:20, pixel...@gmail.com wrote:

 

I did a CL:COMPILE-FILE and it still took quite a bit of time but an answer was produced. (SBCL blows through it instantly).
But that's fine, I still like Medley having CL as an option.

 

--

You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lispcore/b650f9d9-a487-4140-a457-26a1192d1262n%40googlegroups.com.

[Nick Briggs]

On Dec 2, 2025, at 10:25, pixel...@gmail.com wrote:

I think so...

I was using FILESLOAD after each compilation (I thought it loads the DFASL updating the function to the compiled form until edited.)

That only happened to work for you because you called the file DAY2.LISP instead of DAY2 -- so it was confused about whether it was already loaded.

FILESLOAD is not supposed to load a file that is already loaded.

I tried it with just LOAD T as suggested. 

I was talking about (COMPILE-FILE "DAY2.LISP" :LOAD T) -- but you can always (LOAD "DAY2.DFASL") after you've compiled it without the :LOAD T option.

I'll include the Lisp file as well (I guess if anyone wants to try the puzzle for Day 2 themselves don't spoil it with my code. :P)

<Screenshot_20251202_112124.png>

On Tuesday, December 2, 2025 at 10:09:42 AM UTC-7 nicholas...@gmail.com wrote:

Cool.  Did you load the DFASL it produced?  Unless you give it one of the other keyword arguments (perhaps :LOAD T) CL:COMPILE-FILE just compiles it to produce the DFASL  but does not load it back into the system, so you would have still been running interpreted.

On Dec 2, 2025, at 00:20, pixel...@gmail.com wrote:

I did a CL:COMPILE-FILE and it still took quite a bit of time but an answer was produced. (SBCL blows through it instantly).
But that's fine, I still like Medley having CL as an option.

--
You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lispcore/b650f9d9-a487-4140-a457-26a1192d1262n%40googlegroups.com.
<Screenshot_20251202_112124.png><DAY2.LISP>

[pixel...@gmail.com]

Thanks for the clarifications. (I'm still working my way through everything)
I did the steps suggested and it looks like the results are similar but it was worth learning the right way.

So it would appear "thems the results" still. :)

[Nick Briggs]

Yeah, no worries.  I ran your code on my ancient macbook air, compiled, and it took longer than your presumably faster machine.   For fun, I ran

(IL:WITH.SPY (USER::TASK1 USER::*INPUTS*))

(IL:SPY.TREE)

and found where the time was going (approximate percentages in the graph):

and just looking at BIGNUM.DEFPRINT:

To view this discussion visit https://groups.google.com/d/msgid/lispcore/4e354383-cd6a-45ca-9e68-e9cd4bf79334n%40googlegroups.com.

[Matt Heffron]

Are you sure about “but the into clause in LOOP is missing”?

The into preposition is present in sources/XCL-LOOP

It is recognized and expanded.

 

 

From: lisp...@googlegroups.com <lisp...@googlegroups.com> On Behalf Of pixel...@gmail.com
Sent: Monday, December 1, 2025 10:44 PM
To: Medley Interlisp core <lisp...@googlegroups.com>
Subject: Re: Advent of Code starts soon

 

Lisp is pretty well suited in general for quite a few of these.

To view this discussion visit https://groups.google.com/d/msgid/lispcore/9c2900cf-d50f-4e98-8f78-1db09d0c96b7n%40googlegroups.com.

[pixel...@gmail.com]

Here my a test...
Into can introduce new symbols without the with clauses.

[Matt Heffron]

I found the bug. A simple fix.

I’m making the PR.

 

From: lisp...@googlegroups.com <lisp...@googlegroups.com> On Behalf Of pixel...@gmail.com
Sent: Wednesday, December 3, 2025 10:45 AM
To: Medley Interlisp core <lisp...@googlegroups.com>
Subject: Re: Advent of Code starts soon

 

Here my a test...

Into can introduce new symbols without the with clauses.

To view this discussion visit https://groups.google.com/d/msgid/lispcore/7341f95d-d137-4509-b3e5-afcd2764fd76n%40googlegroups.com.

[Paolo Amoroso]

Matt submitted PR #2401 to fix the LOOP issue.

To view this discussion visit https://groups.google.com/d/msgid/lispcore/076b01dc6490%244a7dd120%24df797360%24%40gmail.com.

[pixel...@gmail.com]

Matt,
Excellent work, thanks the early Christmas present. :)

Larry, 
If you've got cool solutions to the Advent and don't mind sharing it'd be cool to see your work.
No pressure though if it turns out to not be your cup of tea!
It's interesting to me to see different styles of Lisp and how people approach it.

Usually the Holiday Season keeps me from finishing all of em but I do a few!

If any additional folks tinker with an Advent puzzle or two, color me interested to see additional code Interlisp or XCL.

[pixel...@gmail.com]

I'm getting there - in some ways it's kind of nice to discover little pieces not yet implemented in Medley Common Lisp.
Think I ran into an issue with multiple value return aka VALUES ...

[Matt Heffron]

Ryan,

What kind of issues with VALUES? 

I've used them without issues.

The only problem that I've ever heard about multiple values is an old (Aug. 2020) Issue 19: Stack overflow in loop that returns multiple values
Matt

[pixel...@gmail.com]

Hello Matt,

VALUES is a useful notion when you expect a function to return one desirable value and silently throw away the rest if the recipient function doesn't want  them.
Some of the math functions are built this way too, providing an additional detail to be optionally collected about the operation.
Here are some examples:
https://www.lispworks.com/documentation/HyperSpec/Body/f_floorc.htm

Well, VALUES also happens to be a valid place to SETF.
This may be a post CLTL1 change (I'm not sure).
Medley Common Lisp gives an error "CL:VALUES is not a known location specifier for SETF".

Here is the Hyperspec with notions of all SETFable places. 
https://www.lispworks.com/documentation/HyperSpec/Body/05_abc.htm

Here is some sample code you can try in both SBCL and Medley.

(defun foo ()
  (values 42 43))

(defun bar ()
  (let (baz qux)
    (setf (values baz qux) (foo))
    (list baz qux)))