yes!

I'm sitting here screaming "just say amb!"

amb means? :thinking_face:

Ambiguous evaluation, writing (amb 1 2) returns a block of code which evaluates to 1 and to 2 (amb 2 fail) evaluates just to 2

Obviously I'm missing some context 😄 Anyway thanks!

@UC1DTFY1G Adding to your context: Leonel (who answered above) has a clojure concurrency library called https://github.com/leonoel/missionary that includes this amb evaluation concept

Perhaps very dumb, but... I was just skimming through missionary gh. Yesterday I was doing something with htmx when this requirement came up: On a ring handler, 1. return a "loading" div which will start long polling on a separate endpoint for the results of the load. 2. Load some data 3. Return the loaded data at the long polling endpoint And I was thinking to myself "What I need is to return twice from this function". Is this a common case?

Common enough. Another common case of multiple returns is an iterator

> which will start long polling on a separate endpoint for the results of the load You may want to know a comcept of a websocket

@U028ART884X I was time constrained and didn't want to risk it. I had some difficulty with htmx oob messages with a websocket before so I decided not to do it.

I'm not advocating you to do it. I have websocket-based model in my current job and it's not that easy because you basically have to write your own protocol.

haha 😄 It just made me think. The entire thing felt like a function that has to return twice if the frontend somehow knew to receive it.

btw, what do I need to read in order to read the missionary stuff?

The missionary wiki and discussions in issues are a good intro

I believe amb comes from https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book-Z-H-28.html#%_sec_4.3.1

I think McCarthy had a paper about amb from the 60s We're way overdue

The idea I would be most interested to hear more about is the builtin "effects system" that he mentions on one of the slides. I checked the paper, but couldn't find anywhere that elaborates on that idea more fully.

He said "transactional memory". Maybe that's a clue :thinking_face:

It's also ultimately a way to enforce DRM. You could prevent someone from connecting the output of a playback device to the input of a recording device using Bluetooth (or something like it)

Headphones could have their own SIM card :thinking_face: And with it their own integrated circuit with internet connection. And you'd buy a subscription. To the headphone pair... that you... own...

You'll own nothing, and you'll be happy 🙂

You'll be nothing and you'll be happy

LOL

There are 2 main markets for external bluetooth radios: 1. Cheap devices with low quality hardware and software aimed at the "average consumer" wanting to add wireless functionality to a device that lacks its own Bluetooth, such as an older home stereo system or a really old laptop. Many of these devices perform even worse than what is built into a modern cell phone. 2. Audiophile devices, which aim to produce the maximum possible audio quality within the limitations of Bluetooth. This will always be a niche market, even smaller market than "audiophile" in general; because the data transmission requirements of Bluetooth forces compromises in quality. These devices are only for the people who put a high enough value on audio quality to pay more and suffer still being partially-wired, but willing to trade down a little for the convenience of Bluetooth.

Oh my god, the chain can be even longer. AM/FM radio device -> BT -> phone -> BT -> AMP -> BT -> headphones Three bluetooths! That's surely a win. These days radio isn't even added to phones... The more choices the consumer has, the happier they are!

FM radio pales in comparison even to Bluetooth. The stack you describe will have absolutely terrible audio quality. Starting with the extremley low quality of FM, each device in the chain will lose even more data through compression and decompression and transmission through the air. (AM radio is too terrible to even ponder here. There is a reason you cannot find music of any kind on music on any AM station.)

> will have absolutely terrible audio quality The quality doesn't matter because as a manufacturer I get to sell 4 devices instead of one with wired earphones 💰

Not if your 4 devices do not at least provide the appearance of some sort of benefit to the consumer you expect to pay for them.

It doesn't need to be a radio, it can be a smart watch, it can be your car, it can be your sneaker

I don't really know what you're getting at. Bluetooth = radio transmission. So, yes it does need to be "a radio". And all the devices you just mentioned are using bluetooth as a feature to sell some more expensive product, rather than trying to get someone to buy Bluetooth transmission on its own.

Otherwise, if that feature is left off, then some Chinese factory is going to sell you direct through Amazon with some cheap radio to fill in the gaps. Standalone bluetooth receivers/transmitters has too much race-to-the-bottom to have the interest of the big corporations that promote the need for bluetooth on everything.

This is the same thing I'm getting at too. Bluetooth seems to be the "lingua franca" of the device "partitioning" that is happening. I wonder how much of this bluetooth padding they can add to the already partitioned devices that we have today :thinking_face:

@U90R0EPHA FM radio is a high fidelity format. I don't know the full potential of BT but I've never heard a BT device yet that was comparable to uncompressed audio over FM. The quality of audio you hear on FM radio today is bad, but that's got nothing to do with the carrier, it's because of the processing the signal goes through before it's modulated. It may also be because the licenser is trying to squeeze more stations into the same bandwidth. In any case, I think the point @U028ART884X is making about the absence of FM from devices is that it's evidence of an effort to remove features from devices to force you to buy more intermediate devices. Personally, I think it's more to do with manufacturers chasing unicorns like compactness, and wanting to remove any components that would increase manufacturing costs. But I also think there's a DRM aspect to it, because inevitably major hardware manufacturers like Apple, and Sony before them, end up getting into the publishing business, and then their devices are at least in part serving the interests of their publishers.

> chasing unicorns like compactness, and wanting to remove any components that would increase manufacturing costs I just bought a phone with 12 gb RAM, microsd card, audio jack, three cameras and CPU which has one 3ghz core. They didn't put in the FM radio but well... the other specs are there. You rarely need three cameras on an iphone, why not have two cameras and an audio jack instead, it's the same amount of space as one camera :thinking_face: So no, I can't agree with the argument of compactness. The software is slow because devices are as fast as ever, they don't need to be that fast. If you accept this kind of "industry trend" then you may also decide to accept your phone becoming a thin-client with some remote cloud. And the sim cards could be hosted in that cloud too because of "form factor". This speed also comes with a cost - the faster the processor, the larger the battery you need. So they squeeze everything because of the speed and the battery to compensate for that speed. Also display. But hey, now that we have this fast CPU... let's run machine learning on mobile processor in the background!

I didn't buy any of these phones in the comparison but I was considering the left one. The left one has memory card and a jack, the right one has a beefy CPU and display: https://www.gsmarena.com/compare.php3?idPhone1=11269&idPhone2=11773 And the interesting thing is that the right one has a smaller battery. They can just get away with it and they do it. Also microSDXC means 1TB memory expansion for $150. So you may want to look at this one for $2k to do the actual price comparison: https://www.amazon.de/-/en/MQC23ZD-A/dp/B0BDJ8G62P/ref=sr_1_3?keywords=iphone+pro+max+1tb&qid=1671192150&sr=8-3

I'm not saying I like compactness, but I think the Apple marketing boffins think that I do. Ironically, their obsession with thinness is what motivated me to leave the Apple ecosystem altogether. I can recommend https://murena.com/smartphones/ if you think one of their phones might work for you. Sadly their flagship Fairphone no longer has an audio socket but the OS is open source so it's annoying rather than concerning, but there are other phones there that do still have the socket.

The argument for a built-in audio socket in a phone is honestly pretty weak. Most people really just never use it, either because Bluteooth is good enough and more convenient or because they don't use their phone for audio at all. If you really want wired audio of similar quality to what would come from a built in jack, an external adapter that you just leave attached to your headphones is a cheap add-on. Searching Amazon for "usb-c headphone adapter" yields https://www.amazon.com/Headphone-Adapter-JSAUX-Compatible-Samsung/dp/B07XYQ2ZKH as its second result. Lack of memory card expansion is not easily fixed with aftermarket products. But it suffers even more from lack of use by the average consumer. Most people just never use an SD slot, even if it is offered.

> argument for a built-in audio socket in a phone is honestly pretty weak No, not weak at all because there are downsides to bluetooth technology. For instance it consumes energy and it's a separate device. I think I heard that having to charge your headphones is not the nicest thing. Charge your phone, then your watch, then your earphones. So three plugs already. And the batteries aren't replaceable. Also losing one earbud is actually pretty unfortunate. If they'd be priced at $9 as that adapter then I'd think about having them. And by using an adapter you make your USB port weaker (basically you're adding a lever into the port) and you can break it easier, so that's probably not a win. Plus you can't charge and use your headphones at the same time.

Arguing the faults of Bluetooth is not sufficient as an argument for building an audio adapter into the phone. That ignores the huge swaths of people who never use headphones at all, and the extremely cheap fix of an external USB adapter for people insistent on wires.

Do you have statistics from those years when the manufacturers decided to remove this feature?

No I don't. But I'm sure they manufacturers do.

I can tell you anecdotally that I almost never see anybody wearing headphones at all in my day to day existence.

and didn't before the loss of that adapter either.

What's the argument here? "I don't use wired connections so you shouldn't use them either"?

No, just that the choice by manufacturers to quit including a feature that most of their customers don't really need was fair.

There is this thing called "Agency problem". You may want to read about it: https://www.investopedia.com/terms/a/agencyproblem.asp

So in this instance the manufacturers are kindly guessing the feature set that the wide public should accept. And if they guess correctly then everyone is happy, right? But they actually don't need to listen that intently because when apple got away then everyone followed and even manufacturers like Fairphone joined them because somehow their "wireless airbuds" with irreplaceable batteries are more env friendly than good old wired earphones that you inherited from your father when you were a kid (mostly exaggerating here). See this video for a reference (I really wanted to buy this overpriced phone but no headphone jack means "close, but no cigar" for me): https://youtube.com/watch?v=bRdL0StldJM

> No, just that the choice by manufacturers to quit including a feature that most of their customers don't really need was fair. That doesn't make any sense. Wired headphones are probably the most common accessory in the world - everybody has them - and yet you're telling me that we all rushed out and replaced our wired headphones with wireless ones, and we all kept using them? That's a pretty unlikely scenario. To be clear, the manufacturers can do what they like, but don't expect customers to tolerate it. I'm ok with it as long as there's fairness in the market.

No. Most people didn't bother to replace them or keep using them; because most people weren't using them to begin with. Of the people actually using them, they either went along with the push for Bluetooth, bought USB adapters, or like you apparently, turned it into a political stance to not buy phones without an audio jack.

It's not a political stance. I bought a bluetooth loupe for my headphones and used it for a few months, but I went back to the wired connection because it was more convenient and the audio quality was better. Martynas has already explained why an adaptor isn't a desirable alternative. With all that considered, the only logical thing left to do is to find a phone that takes a 3.5mm jack, which is what I did. I really don't understand your objection to this.

No objection if that's what you want to do. You do you. 🙂 But personally, I don't think the dirt-cheap audio hardware that you can get with a built-in jack is worth all the fuss. I find the Quedelix 5k to be the best of all worlds. I can run a wire to my belt instead of to my phone. Due to a much better digital-to-audio converter, it produces way higher fidelity than a cheap built-in jack ever could, even after the losses of Bluetooth compression, (especially if your phone includes licensing for the LDAC codec). For maximum sound quality, you can plug into the USB port, with sound that competes well against larger DAC headphone amps up into the $500-$700 price range. But the losses over LDAC are negligible enough that I am usually quite happy getting the benefit of not being wired to my phone. https://smile.amazon.com/Qudelix-5K-Bluetooth-Adaptive-Unbalanced-Balanced/dp/B088F7C976

Fine, but this product is an example of what Martynas is describing. Look at it this way: does a built-in jack prevent you from using an external DAC? No. But the absence of a jack requires me to use an external DAC even when I don't need one.

My swiss knife has a large knife and a small one. If manufacturer decides to remove the small knife then they can still claim that you can perform the same tasks as previously but in reality the tool becomes less useful. Actually I use the small knife more often, but to save space the manufacturer may decide to exclude that small knife and say that nobody was using it. New users won't know what's the point with the small knife, but the old ones would know that now the value of the purchase is not as it's used to be. And there will be the users like you, that bought an even smaller knife as they needed it so now they don't use the original small knife and they don't care that it's going to get removed. The knife in the picture is illustratory. Current swiss knifes have 5 and more tools, they never have only these two knifes, but the small knife is included into almost every one of the knives. So by eliminating full client's daily preference of using audio jack the manufacturer makes the device less useful -- you can't take your friend's audio cord and plug it in to show him a piece of music as nowadays you'll be scrambling the name in their phone in their spotify etc. Of course, there is a personalized playlist for every person, but that's beyond the point -- if you log the music title in other user's phone then the event is saved in their account forever, the transaction isn't between two people anymore, it's between them and a third party that hosts the music. That third party gets to keep the preferences and impressions of both people without revealing anything about itself. So really the problem with audio jack removal is way deeper and it's driven by multiple corporations at the same time. But even if you remove the audio jack and get a bluetooth one, you can't listen to Hi-Fi through bluetooth that Spotify and apple music sell. So they're selling a nonexistent thing if you don't buy that USB DAC that you have. And what I didn't really see is people on every corner using these USB DACs with phones. So they default to what they currently own. https://i.pinimg.com/originals/3d/db/9d/3ddb9d7de8d0125c5edc8a2ae3fc50d1.jpg

If they've removed 1/3 of what they added in the beginning, then which part of the three will they remove next? https://youtube.com/watch?v=GK55ElsVzxM

Actually the "show me your music" request came up during a tinder date this week. I understood that the girl has these white in-ear headphones, and generally the consensus happens to be that it's not worth it to pair them with my device just to show a single song... So instead she unthinkingly opened her spotify app and I said what to put in. She opened it without even asking me, then her next question was "oh, so the artists that you listen aren't on spotifyyy...?". She didn't understand how this could even happen. It was unexpected for her. Then I had to scramble for a different composer in that same music genre, somebody that would be famous enough to exist in spotify. I had the audio file in the phone, it all happened because she learned that she couldn't connect the headphones. We all learned that we can't connect anything to anything anymore. It all happened automatically :thinking_face:

I daren't ask what a successful Tinder date is like for you, but I'm imagining the scene from Demolition Man

Anyway, if that's not a winning argument then you've got no hope!

> successful Tinder date is like for you I don't know either. Still figuring it out. For me it's important that people don't freak out when they find out about something they aren't used to. And this headphone BS has also basically became part of it...

Well, it was fun trying, anyway: > can you write me an emacs function to send the region of text as a question to chatgpg and get a responce back in a new buffer? >> Certainly! Here is an Emacs Lisp function that you can use to send the selected region of text as a question to a chatbot and display the response in a new buffer: >

(defun send-question-to-chatbot (beg end)
>   "Send the selected region of text as a question to a chatbot and display the response in a new buffer."
>   (interactive "r")
>   (let ((question (buffer-substring-no-properties beg end)))
>     (with-current-buffer (get-buffer-create "*Chatbot Response*")
>       (erase-buffer)
>       (insert (chatbot-send-question question))
>       (display-buffer (current-buffer)))))

wip emacs binds https://github.com/benjamin-asdf/openai-api.el

I've been making some updates to my https://github.com/phronmophobic/dewey project, which is more of a public dataset than a library. It seems like providing a public dataset would be a natural fit for the clojure world, but I've run into a few issues. I've been getting some really good feedback from @UPWHQK562, but wanted to see if others had some good resources or ideas. Documenting data Malli and Spec both have great support for programmatically describing data. It provides some documentation, but it seems like both are missing human-oriented documentation like doc strings. Are there any good libraries or examples that do a good job documenting a data format? Making query easy The primary goal is to make the data available. A secondary goal is to make it easy for consumers to start using the data. Ideally, there would be a way to describe that data format so that it can be easily loaded into popular databases. Are there any tools are libraries that help here? Data format I'm currently exporting all data as edn which works pretty well, but there are still a few issues. - It's surprisingly difficult to write readable edn. - Dealing with Medium/Large data. • This isn't really the fault of the data format, but as far as I know, all of the available edn readers require loading the whole dataset into memory. Are there any readers that support reading edn a bit at time? Currently, I've been inserting newlines between elements so that the data is still valid edn, but it's at least possible to read items one a time. Are there other alternatives for making data available piecemeal?

Re: reading edn files a bit at a time I think you could split the dataset into multiple edn files and use a custom tagged literal to link them all.

E.g. ;; dataset_main.edn {:foo [:bar ...]} would become ;; dataset_main.edn {:foo #dewey/placeholder-of "other_file.edn"} ;; other_file.edn [:bar ...]

Right, but then I'm essentially creating my own data format. I'd rather use a standard format if possible. The other down side of splitting into multiple files is that it makes it more annoying to move data around.

> This isn't really the fault of the data format, but as far as I know, all of the available edn readers require loading the whole dataset into memory. Are there any readers that support reading edn a bit at time? I think the approach outlined https://blog.michielborkent.nl/transducing-text.html (original https://www.grammarly.com/blog/engineering/building-etl-pipelines-with-clojure-and-transducers/) works, but of course you have to parse each line to EDN on your own. > line-seq reads the provided stream, going line by line into a lazy sequence, which we then lazily parse using the JSON parser. It is important to note that we cannot just load all the data at once and then write it to the database; it simply won’t fit into the memory. We need an approach that operates on streams of data piecewise. We start with a lazy solution here because that’s what we did initially, and because it is easy to experiment with in the REPL.

That approach only works if both the reader and writer coordinate to make sure that the data is written with chunks written on separate lines. In theory, it should be possible for the reader to read the data piecemeal without requiring the writer to do anything special and would also work for any valid edn (rather than specially formatted edn).

I know this newlines thing probably isn't the most interesting part of your question, and I'm probably missing something, but couldn't you just call read on a PushbackReader wrapped buffered input stream until you hit EOF, and that's a fairly standard approach for clojure/edn? Do you also want to lazily read within a single form?

That works, but also requires the reader writer to break up the data into reasonable sized chunks and the writer to know that the data.edn file is a file with multiple edn chunks. For example, the string, {} [] 42 could be read as you suggest, but I'm not sure what that format would be called.

If that's a standard, I would be happy to use it.

according to https://github.com/edn-format/edn > edn is a set of definitions for acceptable elements. A use of edn might be a stream or file containing elements, but it could be as small as the conveyance of a single element in e.g. an HTTP query param. > There is no enclosing element at the top level. Thus edn is suitable for streaming and interactive applications. which I think suggests that it would be for a .edn file, but I see what you're saying it's not really super commonly done/expected

It's better than what I'm currently doing.

fwiw an example of a reader for this that could not load it all into memory is here: https://github.com/cgrand/xforms/blob/master/src/net/cgrand/xforms/io.clj#L55-L83

Ideally, it would be nice to not have to think about making sure each chunk is a reasonable size, but that's not really a problem for my particular use case.

by chunk do you mean the size of each edn form? or the buffer size on the input stream?

The size of each edn form. If I'm reading it right, if you had a form with a billion elements, that form would be read into memory all at once, right?

yeah exactly

That's not a problem for my use case. Just making sure I'm following.

Yea, that seems like a pretty good approach.

I always thought https://github.com/michalmarczyk/clj-lazy-json was interesting, which lets you read json lazily on a per token level, but it probably is more of an augment for ruling out an approach like that, since it's probably impossible without imposing a lot more burden on the consumers than newlines or custom data readers

Somewhat of a middle ground with json which is more similar to edn-in (nice) than manual control over parsing: https://github.com/bsless/jsonista.streams

Not really the same thing but I recently asked a related question in #data-science, specifically about how to document events & properties: https://clojurians.slack.com/archives/C0BQDEJ8M/p1671096840923619 I haven't received much advice yet, though.

Once you're set on a format, can you publish it via github releases?

https://github.com/phronmophobic/dewey/releases

@U06BE1L6T I think it's pretty similar. Would love to hear if you come up with a good solution