Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Gentlefish]

Yeah, online games gather a lot of data. Unless the devs are retards, they can count exactly how much each weapon is being used for example and their kill rates. Plus heat maps - basically log deaths then plot them on a map as heat values. If too many people are dying at a specific spot, then there's probably a flaw in the map's design.

Or built to purpose - I know there's plenty of killboxes in Counter-Strike maps where it's meant to be get there first and win - usually the positions are reachable in the same average amount of time - what make a map "sided" there is whomever has the time advantage to get into position.

[LoSboccacc]

yeah the only problem is if the same side of a map dies over then 51% of the time

[Skyrunner]

Is changing a project from javascript to typescript worth the effort? :S I'm looking at that possibility but I'm hesitant to make the leap... I'm using d3 for all my DOM manipulating needs.

[LoSboccacc]

Is changing a project from javascript to typescript worth the effort? :S I'm looking at that possibility but I'm hesitant to make the leap... I'm using d3 for all my DOM manipulating needs.

I had that question once. Typescript is very, VERY good. but the problem is if you have one or two libs you depend on which aren't wrapped, that's a huge load of your time just going poof.

So I ran a count of all libraries and features I needed and came to the conclusion that, for me, it wasn't worth it. YMMV. also, what's the backend written in?

[Skyrunner]

Technically my backend is just a nginx server. The data served, though, is generated using Python.

[LoSboccacc]

ah! hardcore then

well was just asking because another stuff to watch out is your development pipeline. you usually don't want to wait a build cycle to test out a one liner change, but I only have stuff for eclipse/java

[Skyrunner]

I'm not hardcore, it's just that this app is entirely client-sided A thick client, so to say.

[MorleyDev]

I had that question once. Typescript is very, VERY good. but the problem is if you have one or two libs you depend on which aren't wrapped, that's a huge load of your time just going poof.

There's a quicker way of working around this than creating a whole definition for the library. Create a .d.ts file that just contains:

Code: [Select]

declare module "whatever" {
   var whatever: any;
   export = whatever;
}

Though it does mean you are then essentially back in Javascript land for that library, so none of the static type checking benefits.

Is changing a project from javascript to typescript worth the effort? :S I'm looking at that possibility but I'm hesitant to make the leap... I'm using d3 for all my DOM manipulating needs.

We use are currently migrating to Typescript at my office. It depends on the project set-up and complexity. We do full-stack work, Angular SPAs talking to Web APIs. So for us Typescript is pretty damn useful, though the migration process does require a but of work.

Since Typescript is all based around ES6-style imports so you need to introduce one to get the most benefits. Which usually turns the work into a multi-step process:
1) Migrate from script tags to ES6 (via babel) and package management/minification (We've found JSPM 0.17 is good for this as it gives you both of these alongside the possibility for things like hot reloading).
2) Migrate to Typescript (Can be done progressively when using JSPM 0.17 thanks to plugin-typescript).

Smaller websites benefit less from Typescript. Babel may be worth looking into so you can still play around with the ES6 features though. It's a good language to work with when maintainability is a concern, which for large SPAs is definitely true.

(d3 does have definitions for Typescript, btw).

[Skyrunner]

It's only a thousand lines of code, but I've just changed the data format of the input files radically, so I need to rewrite a lot of random parts of the code anyways. I've also had a ton of headaches because of typing in the past, because there's a bunch of filtering and condition logic in there, so I'm considering making the leap.

I just don't know where to start rewriting it though...

[Antsan]

Today I wrote my first Makefile ever. I realized that keeping my compilation stuff for Poslin just laying around somewhere in some badly-written scripts was a bad idea.

So I came up with all of this:

Code: [Select]

all: build/poslin0
.PHONY: all

build/poslin0: # unholy amounts of file dependencies
sbcl --noinform --disable-ldb --lose-on-corruption \
--dynamic-space-size 8192 \
--userinit ./sbclinit \
--load ./compile-poslin.lisp
mv -v ./poslin0 build/poslin0

.PHONY: clean
clean:
rm -vf ./build/poslin0
That's pretty straightforward, even if I never wrote a Makefile before.
But an install target is still missing, and of course I want an install target. Having an install target is absolutely crucial, right? *seriousface*
Just as important is for the user of the makefile to specify the prefix for the install, so of course I wanna accommodate that. But there will need to be two startup scripts, to not only load the barebones version of poslin (called "poslin0"), but also the one with the base library loaded (poslin1) and the one where fancy stuff like packages and generic operations and optimization stuff and so on is also defined (poslin).
So the Makefile turns into something like this:

Code: [Select]

PREFIX ?= /usr/local
BINDIR ?= $(PREFIX)/bin
LIBDIR ?= $(PREFIX)/lib/poslin
P0 = $(BINDIR)/poslin0
P1 = $(BINDIR)/poslin1
P2 = $(BINDIR)/poslin

# see above

.PHONY: install
install: all
mkdir -pv $(BINDIR)
mkdir -pv $(LIBDIR)
cp -rv ./lib/* $(LIBDIR)/
cp -v ./build/poslin0 $(P0)
echo "#!/bin/sh\n" > $(P1)
echo "$(P0) $(LIBDIR)/base.poslin" >> $(P1)
echo "#!/bin/sh\n" > $(P2)
echo "$(P1) $(LIBDIR)/supplemental/package.poslin \\" \
>> $(P2)
echo " $(LIBDIR)/supplemental/generic-op.poslin" >> $(P2)
chmod +x $(P1)
chmod +x $(P2)
But that's not completely correct. The commands in the resulting scripts need to end with a "$*" so the user can supply additional poslin files to load.
The naive version of course doesn't cut it, because those "$*"s would be expanded immediately, which is bunk:

Code: [Select]

echo "#!/bin/sh\n" > $(P1)
echo "$(P0) $(LIBDIR)/base.poslin $*" >> $(P1)
echo "#!/bin/sh\n" > $(P2)
echo "$(P1) $(LIBDIR)/supplemental/package.poslin \\" \
>> $(P2)
echo " $(LIBDIR)/supplemental/generic-op.poslin $*" >> $(P2)
So I need to escape those "$" characters:

Code: [Select]

echo "#!/bin/sh\n" > $(P1)
echo "$(P0) $(LIBDIR)/base.poslin \$*" >> $(P1)
echo "#!/bin/sh\n" > $(P2)
echo "$(P1) $(LIBDIR)/supplemental/package.poslin \\" \
>> $(P2)
echo " $(LIBDIR)/supplemental/generic-op.poslin \$*" >> $(P2)
But no, that's not how you escape "$"s in sh – this even complains about unclosed quoted strings or somesuch nonesense. You need to use "$$"!

Code: [Select]

echo "#!/bin/sh\n" > $(P1)
echo "$(P0) $(LIBDIR)/base.poslin $$*" >> $(P1)
echo "#!/bin/sh\n" > $(P2)
echo "$(P1) $(LIBDIR)/supplemental/package.poslin \\" \
>> $(P2)
echo " $(LIBDIR)/supplemental/generic-op.poslin $$*" >> $(P2)
Hm. That also doesn't work. I don't remember what exactly happened here, but I think those "$$*"s just vanished entirely. Probably because the substitution of variables is done from the right or something, what the heck do I know!
Okay, then maybe make the "*" stay away from the "$$":

Code: [Select]

echo "#!/bin/sh\n" > $(P1)
echo "$(P0) $(LIBDIR)/base.poslin "$$"*" >> $(P1)
echo "#!/bin/sh\n" > $(P2)
echo "$(P1) $(LIBDIR)/supplemental/package.poslin \\" \
>> $(P2)
echo " $(LIBDIR)/supplemental/generic-op.poslin "$$"*" >> $(P2)
And it works!

Damn, this is ugly. How does anybody get anything done in bash?

[Telgin]

If I have to script something that's anything more than literally just a series of commands, I don't bother with Bash scripts.  I can get much, much more done with a scripting language like PHP or JavaScript than I can with a Bash script, and with much less effort.  I'm sure if I actually knew the language well it would be different, but since I always have one or both of those interpreters installed on any system I'm working on, there's little point in learning the Bash script syntax.

I distinctly recall also thinking that the syntax was hideous.  Kind of like init.d scripts for Linux services vs. systemd scripts.

Of course, just using it straight as a shell it's great.  Until you accidentally put a ! in a command argument somewhere and wonder what the heck it's going on about in the error messages it gives you.

[pisskop]

I hope to learn to do more in codes.  Im not aiming for the stars or anything, unless they fall into my lap.

[MagmaMcFry]

a scripting language like PHP or JavaScript

PHP? Javascript? Get yourself a real high-level scripting language, like Perl.

[Antsan]

I would use any of those languages (well, maybe not php), but I'm not quite sure I could write a Makefile with those.

[Orange Wizard]

PHP? Javascript? Get yourself a real high-level scripting language, like Perl.

pythonmasterrace