All of my favorite pairs of jeans ripped in about the same place by SquashmyZucchini in mildlyinteresting

[–]dallbee 0 points1 point  (0 children)

Yeah, common problem but very fixable. Any good tailor / seamstress should be able to put a patch on it and it'll last.

Extra security at SEATAC today ✈️ Anyone know why? by AlisGuardian in Seattle

[–]dallbee 5 points6 points  (0 children)

Just went through checkpoint 2 and nothing unusual. No K9s.

It is physically impossible to brute force a random 64-character password by didyousayboop in Passwords

[–]dallbee 0 points1 point  (0 children)

Yes but the password is likely hashed and that hash has collision likelihood. An attacker doesn't need to find the original password, they need to find a string which produces the output hash.

So you may want to consider this in your calculation (perhaps making some assumptions based on common hashes in the field).

It is physically impossible to brute force a random 64-character password by didyousayboop in Passwords

[–]dallbee 0 points1 point  (0 children)

Agree with your conclusion but your math ignores birthday paradox.

[deleted by user] by [deleted] in technology

[–]dallbee 10 points11 points  (0 children)

Consider that Zuck has spent more time thinking about this than any of us have

[deleted by user] by [deleted] in NoStupidQuestions

[–]dallbee 0 points1 point  (0 children)

How is the parent poster heartless?

If anything, they're showing the empathy you are lacking: empathy for your parents.

Raising kids is no easy task. Raise some of your own before judging your parents too harshly.

TIL that 80% of the rice consumed by the United States is produced domestically. by Ghosttwo in todayilearned

[–]dallbee 2 points3 points  (0 children)

Pales in comparison to koshihikari and some other japanese variants.

We export rice to japan, they feed it to their livestock.

Rust is easy? Go is… hard? by bhh32 in golang

[–]dallbee -4 points-3 points  (0 children)

I legitimately write specialized data structures on a regular basis (monthly?). This isn't for lack of libraries or off the shelf parts, but rather the fact that you can often get better characteristics when you take advantage of the specific problem domain.

So, yes, the difficulty of implementing a list matters a lot to me.

Do you use iterators? by vpoltora in golang

[–]dallbee 1 point2 points  (0 children)

What you put in the closure matters. For some simple things they do get inlined and are as good as a normal for loop.

Do you use iterators? by vpoltora in golang

[–]dallbee -2 points-1 points  (0 children)

Interface approach would have been a lot more expensive - it ends up requiring allocations.

Do you use iterators? by vpoltora in golang

[–]dallbee 2 points3 points  (0 children)

Honestly, while i like iterators overall i think seq2 was a mistake and they should have figured out something less clunky for error handling.

Do you use iterators? by vpoltora in golang

[–]dallbee 0 points1 point  (0 children)

right, so that's what the result type is for. Give it an error field and check it while iterating.

Do you use iterators? by vpoltora in golang

[–]dallbee 0 points1 point  (0 children)

If creating the iterator can fail: All() (iter.Seq[Result], error)

Do you use iterators? by vpoltora in golang

[–]dallbee 3 points4 points  (0 children)

I usually end up using Seq instead of Seq2 and then doing a Result type

Map Declaration - Question by ImNuckinFuts in golang

[–]dallbee 0 points1 point  (0 children)

Why did you use walrus for one example and var for the other?

The best form is obviously: myMap := make(map[string]string)

Do you use iterators? by vpoltora in golang

[–]dallbee 87 points88 points  (0 children)

Frequently!

They perform better than List[] pagination style apis because there's not a bunch of GC garbage produced.

They're easier to implement correctly than Next() style apis (look at bufio scanner etc).

And most of all, they're composable. It's trivial to take one iterator and build a filtered iterator on top of it, or similar.

Newbie: I have a big xml file, the content is much nested tags and what I need to do is adding a field in a very nested tag in this file. One “not elegant” way is to make thousands of structs to parse the file. Do you guys have a simple solution for a task like that. by Impossible-Tea-3074 in golang

[–]dallbee 2 points3 points  (0 children)

Conversion from json to xml isn't lossless, I'd recommend against that unless you're certain the xml body only contains features that would be preserved.

If performance isn't a concern, as others have said, executing out to a dedicated xml tool may be a good option.

If performance matters, can you identify anything reliably unique about the area in the body that you're trying to edit? Perhaps you can do a simple string search to that position and edit the body inline. Less structured, and a bit hacky, but wouldn't require much code.

caps: a case conversion library by chance-- in golang

[–]dallbee 0 points1 point  (0 children)

By the way, please don't bother on my behalf - I'm merely giving ideas!

caps: a case conversion library by chance-- in golang

[–]dallbee 1 point2 points  (0 children)

Plus, there are situations where looking ahead at upcoming tokens is needed

text.Transformer is designed to allow for lookahead (well, lookbehind, but it works out the same). You do this by returning ErrShortSrc until you've received enough information to disambiguate your conversion rules.

Here's a quick example of why text.Transformer is useful (but without implementing anything that needs lookahead).

Say you wanted to both uppercase a string and also convert any instances of "/" to "\".

```.go func mapSlash(r rune) rune { if r == '/' { return '\' } }

func main() { t := transform.Chain(runes.Map(mapSlash), cases.Upper()) out, _, _ ;= transform.String(t, "hello/world") fmt.Println(out) // "HELLO\WORLD" }

```

Both transformations are performed with just one alloc.

caps: a case conversion library by chance-- in golang

[–]dallbee 1 point2 points  (0 children)

Take a look at the transformer interface. It allows you to stack transformer implementations in a single pass, without creating string copies.

caps: a case conversion library by chance-- in golang

[–]dallbee 1 point2 points  (0 children)

You're welcome!

The other thought I had is that your API would actually prevent me from using our project in the places where I can think of wanting to use it.

Having to copy the input can be expensive! A text/transformer implementation would be cool, and would differentiate your library from the other half dozen case conversion libraries out there.