Fork me on GitHub

Anyone have much experience with Azure Application Gateway (v1)? Is it normal to spend 30-45 minutes waiting for every configuration change to take effect or am I somehow cursed?

Ivar Refsdal08:08:06

We are on V2 here. . We pretty much only add/remove/update IP addresses, and that's usually instant. We've had a lot of "firewall"/network issues though inside the VNet, not sure how common that is.


Thanks. I've been trying to help someone out today with recovering a deleted gateway from a copy of the resource json, and it's been a real treat. Probably could've created the new gateway as v2 but didn't seem like the time to experiment and I had no idea the configuration latency on v1 was this bad.


Currently have a saving changes activity that's been running for over an hour.

Ivar Refsdal09:08:19

Ouch. How do you save the change? Using the az cli? We're on terraform (somehow, don't know the exact details) + az cli for simple updates...

Ivar Refsdal09:08:17

(We've had a lot of issues with Azure Container Instances, so I feel your pain, though I doubt that helps very much :-/)


Mostly via PowerShell, couple changes directly in the portal just to try to poke something. The worst part is that it wasn't sending health checks to 3/4 of the backends configured until the configuration settled so they wouldn't come up.


Everything started working this morning about 6 hours after the last config change.

😩 1

> Dear Common Lispers, > > Common Lisp has the most expressive power of any modern language. It has first class functions with lexical closures, an object system with multiple-dispatch and a metaobject protocol, true macros, and more. It is ANSI standardized and has numerous high-performance implementations, many of which are free software. > > In spite of this, it has not had much success (at least in Japan). Its community is very small compared to languages like Ruby and most young Lispers are hacking with Clojure. > > Why? Common Lisp is much faster than them. Ruby has no macros and even Clojure doesn't have reader macros. Why then? > > Because these languges are well-designed and work for most people for most purposes. These languages are easy to use and the speed isn't an issue. > > Is Common Lisp sufficiently well-designed? I don't think so. You use different functions to do the same thing to different data types (elt, aref, nth). You have long names for commonly used macros (destructuring-bind, multiple-value-bind). There is no consistency in argument order (getf and gethash). To put it simply, the language is time-consuming to learn. > > Given this, how can programmers coming from other languages believe Common Lisp is the most expressive one? > > Fortunately in Common Lisp we can improve the interface with abstractions such as functions, macros, and reader macros. If you believe our language is the most expressive and powerful language, then let's justify that belief. > > We should consider the future of the language, not only for ourselves but for the next generation. from Thought this was interesting.


I gotta say, I've been a bit tempted to give CL a go ever since I read this blog post about optimizing CL code and seeing how fluidly you could see the actual assembly code generated by the CL compiler:


Looks like at least one disclaimer has been issued about CL21 though:

Noah Bogart18:08:09

Yeah, sadly, it never got any traction, seems like most of the CL community dismissed it 😿


there was an interview with Rich years ago, where they asked something like "if you had to use a language that wasn't clojure what would you use?" and the response was something like "I could be very happy on a desert island with a common lisp implementation and its source"


I think the comment on well-designed is apt though, I think it's partly why I like Clojure, Lisp and all is cool and I love all the power and expressivity, but then the core library, literals, and main abstractions the community adds really matter. Even in Clojure, the only things I dislike are little missteps with those.

Annaia Danvers18:08:03

the problem with Common Lisp is that it wasn't designed, it was assembled.


As a side-note, the Clojure code in that article can also be optimized to run much faster, the author just chose to have some fun with CL instead.

Annaia Danvers18:08:01

It's just bits and pieces of a dozen mostly similar pre-CL Lisp-2 dialects mashed together by a committee, and that's why you get so many weird edge cases and conflicting behaviors and strange syntax and naming conventions.

👍 2
☝️ 1

Ya, that makes sense

Jeongsoo Lee18:08:43

The most jealous feature of CL is the condition-restart system; the running (compiled) program can recover from error and pick itself up from that on. Although I’ve seen a condition library for Clojure somewhere, CL is still cool that it has that in its standardized lang spec.


@U0K064KQV it's not just about the speed IMO; the ability to so easily see behind the curtain of language abstractions all the way is also very enticing. It seems like also exist for Clojure, but only down to the level of JVM bytecode and not the "bare metal" of x86 assembly.


java -Xbatch
This will print the assembly code when the JIT compiles it


So as your app is running


And you can use to at the REPL print the Java or the JVM Bytecode of some Clojure form

☝️ 1
Noah Bogart19:08:00

@U01LJQRJ2AU check out farolero: it's the best version of CL's condition system in clojure yet

☝️ 1
😮 1

Seeing the generated Java or JVM bytecode with clj-java-decompiler is pretty much as easy as what CL does. Seeing the JIT compiled Assembly is a bit more complicated, but Java is not compiled ahead of time, I suspect CL is? Maybe some of its implementations at least are. So anyway, sometimes code will be interpreted, and the JIT will compile as it goes. So best you can do is get it to print when the JIT compiles it as it runs.

Noah Bogart19:08:08

yeah, the clj-java-decompiler fundamentally changed how i write clojure, it's extremely cool


But even then, the JIT will recompile code as it becomes "HOT", so its very hard to know like what exactly is the assembly, it'll depend on the level of optimization and the profiling of the hot code it has performed


I think you seriously overestimate the usefulness of having the assemly version of your code. This is of course perfectly possible on the jvm as didibus said but unless you are true expert you are just gonna get lost. It's cool to be able to see the assembly but that's about it

Ben Sless05:08:45

Regarding clj java decompiler, it also has nice integration with emacs :) I partially agree regarding the usefulness of disassembly. Performance doesn't matter until it does, and while you often don't get to those levels, being able to read the bytecode helped me understand what I was doing that hurt performance with primitives. Profiling will be more beneficial most of the time, though.


Wow, sets in Java are pretty bad, can't even get an element from a set cause it assumes its all object identity based and not value based


do hashcodes work?


There's simply no method


There's only contains which returns true/false


So if you override equals and hashCode to have value semantics, the set is basically worthless


i mean hashcode for your objects in the set


then you can ask the set for an obj with a matching hashcode


i'm not sure if sets respect hashcode, though, but i thought that was a fundamental part of java

Daniel Craig21:08:56

Could you use records from java 17?

Daniel Craig21:08:26

or are you not using java 17? If you are, I would suggest them.


are records java's value types?


> then you can ask the set for an obj with a matching hashcode No you cannot, there is no method for this on the Set interface


Well, I need metadata, that's why I can't use record, instead I override equals and hashcode to only contain the fields which are my value data, and the other fields are my meta


U sure? It's no clojure but you can iterate a set (java 17)


implementing hashcode and equals was how you live in the java world, until records came along


Ya, you can implement your own linear search, but why are you using a set in that case?


Just use a list then 😛


Just try it, create a simple class with two fields, make one of the two fields part of equals and hashCode. Create a few of them, put them in a set. Now imagine you want to find the entry equal to another and modify the other field that's not part of the equals or hashCode.

😱 1

You can do it with a linear search, but there's simply no get method


Oh, I think you may wanna look into java.util.HashMap for use case you mention, a set in java is not intended for lookup is meant to check is the element is present or not


Yes, that's why sets in Java sucks compared to Clojure 😛 hence my comment about it


I've switched to a hashmap, but its a bit more annoying using a hashmap when I want set semantics


after reading the stack overflow questions I think there is a mistake in concepts a "set" is not an "index", I don't see how you can do what the post says with a plain set in clojure either.


(def s #{[1] ^:even [2] [3]})
(meta (get s [2]))
;> {:even true}


(def s #{[1] ^:even [2] [3]})
(let [e (get s [2])
      new-e (vary-meta e assoc :prime true)
      s (disj s [2])
      new-s (conj s new-e)]
  (def s new-s))
(meta (get s [2]))
;> {:even true, :prime true}


So in Clojure I can get elements of the set by value equality O(1) lookup, change their meta, and update the element with one with new metadata on it.


I don't really understand the point of a Set over just a List or Vector if its not so that you get O(1) lookup by value


you are using the set as a map, just use a map


I'm not though, I'm using the set as a set. You can use a Map like a set, but its different.


If I use a Map like a Set I need to make sure the key and value are always in-sync


The value semantics in Clojure make sense, things are equal when they have equal data. Additional per-instance metadata can be attached, this does not play with the equality. Now you use a set with this, and it all works, you can retrieve the previously inserted instance through equality O(1) lookup, and get the metadata of that prior instance. Perfect. In Java, things are equal as per .hashCode(), so I override it and exclude the fields that are my metadata. Java Set does O(1) lookup as per hashCode, but it can't return you the item that matched, so you can never retrieve the fields that are not part of its value semantics.


agree that list are O(n), intended for transversal/reduction. map are for lookups ~ O(1) set is no build for lookup, they are to check is something exists in the set I wouldn't use meta for that, with a hashmap you only need to "sync the value"

(def m {[1] {} 
        [2] {:even true} 
        [3] {}

(get-in m [[1] :even ])

(assoc-in m [ [1] :prime] true) 


> set is no build for lookup, they are to check is something exists in the set Java sets are like that, but not Clojure sets, aka, Java sets are less useful as Clojure ones since they do less things.


java is low level language compared to clojure, in java you will have to implement part of clojure to apply clojure thinking


(or just import clojure from java)


Java devs would disagree, Java and Clojure are supposed to be the same "tier" of language. Also, its not just Java, C# supports the same, TryGetValue is used to get an element from a set in C#


I'm sure other languages have the feature too. Java is just missing this feature for some weird reason


I’m not sure about the premise of this thread


Java Sets use .equals()

✔️ 1

The premise is that Java Set has no get method, only contains


But are you saying that even contains is O(n) in Java with a Set and uses .equals in a linear search for it?


I doubt, since its HashSet, should be using hashCode no?


No, I saying, you are confusing a set( used to test membership) with a hashmap(used to do lookups)


So Clojure and C# also are confused and only Java is not confused, ok :man-facepalming:


most likely C# 😁

clojure-spin 1

Basically, you're using a No True Scotsman fallacy. Clojure has Sets, they support Get. C# has Sets, they support Get. Saying they are not true sets because real sets don't support Get is a fallacy. None of those things are mathematical sets, they are all just a data-structure with properties and operations that you can use to make your life easier and model your data. Java Sets are missing an operation that I would need, making it I have to use a Map which isn't as easy in my case. Clojure and C# have set with a Get, and that's awesome and makes my life easier.


And my point, was just another realization how well thought out the data-structures in Clojure are, and how much nicer they are to work with than Java's, that's all really 😛


> Saying they are not true sets because real sets don't support Get is a fallacy > -@U0K064KQV That's not an argument that anybody made. Nobody ever said (or even vaguely implied) that a Get method excludes a Set from being a Set. The point @U487Z32UF made is that the intended use-case which Sets are designed for is testing for membership. Since Clojure allows you to append metadata, then ignores that metadata in it's value semantics, while providing facilities to update that metadata, you are able to bend a Set's behavior into that of a HashMap. Does that mean that Clojure's Sets are better than Java's? Well, maybe. But does that mean that Java Sets lacks the features expected of a Set? No. Nothing about Set semantics implies you should be able to use it as a HashMap. The usage you describe is equivalent to a HashMap, you are just using the Value as a Key and MetaData as a Value. I'm sorry for you though that you must jump through extra hoops to get your work done, because you are stuck in Java. 😢

👍 1

This thread got me wondering if people use Clojure as a library in their Java / Kotlin projects? In OP's case, it would be overkill to do so, just for access to Clojure's hash-set semantics. But the musing stands. I do wonder!

Martynas M06:08:29

Why not use Map of your-value->metadata ? This way your keys will be your values and the map's values will be your metadata :thinking_face: Set is just a Map where items either exist or not. I.e. if you're forced to separate because you override the hashCode/equals then you can separate it even further.


Because I want my metadata contained to my entity as it moves around the application, the meta is created somewhere else when the entity is created, and only much later do I put some of those entities into a set.

java 1

@U90R0EPHA I feel you're applying the same fallacy. You're telling me your definition of a set, and then saying that by your definition it is my fault for thinking that something of that definition would do something else. This means you're assuming the role of the gatekeeper, the only person that has authority on what a true set is. And by your definition my use-case for it is wrong. But by some other definition, a set can have a get method, allowing it to test for membership and return the member that matched. I find this semantic argument pointless. Someone else could come and say a real set doesn't even test for membership, but only list the possible values much more like an enum. And claim that therefore Java's sets are wrong to even have a contain method. You're right that the Set interface in Java can only be used to test for membership or list the values in the set linearly. I'm not sure that you're correct about the intended use-case for them though. In my research, it looks like people say that it was assumed if the set contains your object, you have the object, so no need to get it from the set. But that assumes default hashCode and equality which is based on object identity, same object in memory. In that case, if you have the object and it's in the set no need to get it from the set. Once you add value semantics you realize this is no longer the case, as you define some values to be the identity and not the instance of the object itself, then you can't rely on that anymore. Clojure doesn't have metadata by accident, it's how you can attach data that does not participate in the value semantics of your entity. And the fact is Clojure has a get for sets, they had to go out of their way to add it, this seems like a conscious design choice to me, they could have only supported contains? but added get. Clojure could also have chosen to not support metadata, and tell everyone to just track metadata in a separate hashmap, but clearly that's not as ergonomic and trickier to do, in my opinion metadata is a great idea. To put it another way, would you oppose a JEP that adds a get method on Java sets similar to Clojure and C#? If yes, you think it's a bad idea, I'm curious why, if no, than we're just in violent agreement.


@U051MHSEK Asked about folks using Clojure as a "library" language from Java/Kotlin -- I don't know about from those languages but the way we introduced Clojure at work was as a "library" and we called into Clojure from CFML (ColdFusion). I gave a talk about this at Clojure/West many years ago. The CFML is almost all gone now (we have one small, low-traffic app still running on it), as the use of Clojure expanded from the bottom of the call stack upward, eating all of the CFML as it went 🙂 Even that one remaining CFML app calls into Clojure for much of its functionality.

gratitude 1
fist-bump 1
gratitude-thank-you 1

This thread got me wondering if people use Clojure as a library in their Java / Kotlin projects? In OP's case, it would be overkill to do so, just for access to Clojure's hash-set semantics. But the musing stands. I do wonder!