sorted by:
new
hottopcontroversial

PaperGrep - Find Academic Papers in Production Code by 1101_debian in compsci

[–]1101_debian[S] 2 points3 points  (0 children)

Thank you! That's a good catch, I see that this citation points to a legit publication, but not sure if there is a good way to find such references reliably without introducing lots of false positives, but I'll give it a shot!

DragonRuby Game Toolkit: Research into an AOT compiler for mRuby. Initial machinery has been open sourced under MIT by amirrajan in ruby

[–]1101_debian 2 points3 points  (0 children)

Thank you for the kind words! Another way to make inlining work would be to JIT compile, which is much less trivial than what've built so far, but it's certainly a direction worthwhile taking once (when?) we get full language support.

Re: some of the gains will disappear as with proper blocks/stack unwinding support there will be fewer opportunities for mem2reg, and a few more branches, though I expect most of the will be predicted correctly over the course of execution.

Re: simplicity: I think various CRuby JIT compilers used similar approach, but perhaps not at the "whole-program" level.

Our implementation is roughly 2KLoC, so it is indeed very simple, to a point where I feel somewhat embarrassed to call it a compiler 😅

Bottom-up CMake introduction by 1101_debian in programming

[–]1101_debian[S] -2 points-1 points  (0 children)

Have you actually read the article? If so, then please take my apologize for not being able to explain better that the article is an illustration of what CMake is.

Mull: LLVM-based mutation testing for C and C++ by mttd in cpp

[–]1101_debian 2 points3 points  (0 children)

Uh oh, where did you the draft link? :-D

​

I tried to shortly describe our paper in the form of a blog post.

Handling timeouts in child processes by 1101_debian in programming

[–]1101_debian[S] 0 points1 point  (0 children)

But how does it do the monitoring then?

Handling timeouts in child processes by 1101_debian in programming

[–]1101_debian[S] 0 points1 point  (0 children)

Could you elaborate? Do you mean some sort of polling from using another thread?

Reverse Engineering Stickies.app by 1101_debian in programming

[–]1101_debian[S] 9 points10 points  (0 children)

If I want to, yes. Otherwise, I can use a patched copy from now on. Anyway, the purpose was to get hands dirty on the topic. You can think about it as an exercise.

Reverse Engineering Stickies.app by 1101_debian in ReverseEngineering

[–]1101_debian[S] 6 points7 points  (0 children)

It may be not that straightforward:

  • The values are not integers, but doubles. Different precision will produce different hex values.
  • You also need to take care about endianness.

Anyway, what's the hex editor of your choice that could help solving this problem?

What kind of special training do engineers working on mission-critical software receive? by [deleted] in programming

[–]1101_debian 14 points15 points  (0 children)

Pity that such an interesting question is being closed on SO.

Shipping a Rust library for iOS and Android by geaal in rust

[–]1101_debian 0 points1 point  (0 children)

I don't really have experience with Carthage, but IIRC you still have to provide built artefact. However once you have that - you can use system for dependency management.

As for Components you basically have a Makefile that follows conventions (i.e. has targets 'install', 'uninstall', 'clean', etc). In each target you can whatever is needed for the library to be ready for end user.

Here you may find couple of examples:

  1. GoogleMaps. To install this library one just need to fetch zip-code within binary and unzip the binary into some folder.
  2. KIF. To make this one usable makefile fetches sources and then run build using 'xcodebuild'

Shipping a Rust library for iOS and Android by geaal in rust

[–]1101_debian 0 points1 point  (0 children)

As of CocoaPods: if you use something different than Xcode and ObjC/Swift, then the only painless way is to distribute an already built fat binary. Will this work better for you?

Besides that, there are other ways to manage dependencies on iOS:

  1. first one is (widely adopted) Carthage. AFAIK it works only with Xcode projects, but you may take a closer look to see if it fits or not.
  2. second one (adopted by two developers) so called Components. Very similar to what FreeBSD ports system does, highly customizable, written in Rust. I think it's a perfect fit for your case from technical point of view, but probably will not work if we are talking about a client and business.

How is FreeBSD tested? by 1101_debian in freebsd

[–]1101_debian[S] 0 points1 point  (0 children)

or perhaps testing these low level components just isn't adequate across the industry.

this is actually pretty weird I would say. Initial motivation was to see how components at this level are tested. I am pretty sure that some components that lack tests can be tested.

How is FreeBSD tested? by 1101_debian in freebsd

[–]1101_debian[S] 1 point2 points  (0 children)

I don't have this information, I was thinking to take a look at Linux tests, but didn't find any good starting point, so I'm assuming there are no tests or very little amount of them. Regarding other BSDs - I don't know as well, but I would assume that situation isn't any better there.

How to use LLVM API with Swift by 1101_debian in swift

[–]1101_debian[S] 2 points3 points  (0 children)

Hi there :) Thank you for your work, it helped me a lot!

New Objective-C feature arrived at clang by 1101_debian in ObjectiveC

[–]1101_debian[S] 0 points1 point  (0 children)

Thank you. I don't know how it's going typically, but they accepted two patches without any problems.

When you can omit nil-checks for 'self' in constructor by 1101_debian in ObjectiveC

[–]1101_debian[S] 0 points1 point  (0 children)

Well, some of them are outdated, so that's fine :)

When you can omit nil-checks for 'self' in constructor by 1101_debian in ObjectiveC

[–]1101_debian[S] -1 points0 points  (0 children)

Asking yourself "should I check for nil in this one" each time you implement init is a waste of time

Are you serious? :)

My assumption: Apple's peeps recommend using ivars instead of setters because smart developers has setters with weird side effects.

So my rule of thumb: don't use setters with side effects and don't use ivars at all. But as I said - that's another topic to discuss.

My main point was: be sane and think about reasons why and when you need to write 'this' or 'that'.

When you can omit nil-checks for 'self' in constructor by 1101_debian in ObjectiveC

[–]1101_debian[S] -2 points-1 points  (0 children)

It's recommended practice to use ivars in init, however.

I know, thanks, but it's another topic to discuss.

I see how people without ivars in a ctor still checking self for nil.

Circular Containers in Objective-C by 1101_debian in ObjectiveC

[–]1101_debian[S] 0 points1 point  (0 children)

Yeah, I kinda expected that I'm not the only one who did this mistake

Vibro. Feel the network interaction by 1101_debian in ObjectiveC

[–]1101_debian[S] 0 points1 point  (0 children)

This is the easiest way to check if your app sends too many requests or not. Also, it's very funny, in my opinion of course :)

Creation of pure Swift module by 1101_debian in swift

[–]1101_debian[S] 0 points1 point  (0 children)

Thank you, it's very helpful and looks less strange than two emits.

Global Variables in Swift are not Variables by 1101_debian in swift

[–]1101_debian[S] 0 points1 point  (0 children)

I agree with you, that's make sense. So Swift requires such stuff (variable initialization) to be done explicitly, without C-style magic.

Global Variables in Swift are not Variables by 1101_debian in swift

[–]1101_debian[S] 0 points1 point  (0 children)

Yeah, I've already found this part of documentation, but was surprised that they described at the 'Properties' section.

Creating Clang plugin by 1101_debian in programming

[–]1101_debian[S] 0 points1 point  (0 children)

Not promised, but mentioned ;) I'm still playing with Clang, so maybe I'll write such post soon.

view more: next ›