Playing with a graph database is actually quite fun, after I'm through the hilariously bad tutorial for this particular one. But for testing purposes I'm creating grid graphs and now I got carried away. I decreased creation time for the database with a 100x100 graph (so 10k nodes and ~20k links) by the factor 20, so I thought it might be nice to try 1000x1000 (so 1 million nodes, ~2 million edges) and this thing is taking a loooong time. ;-)
Oh hey, it occurs to me: Can I tell the Java VM to use more of my RAM? It's only using like 200MB and the database itself is already >500 so it's probably slowed a lot by hard drive access.
-Xmx512m
That increases it to 512MB. (It's a VM Option)
Remember that's allowing for a maximum of 512, not starting the VM at 512.
-Xms512m would set it at startup.
And if you do threading -Xss512m would allocte 512 a thread.
0
Options
baronfelWould you say I havea _plethora_?Registered Userregular
Oh man, i18n issues are the best! Especially in regards to dates and monetary values.
We're bolting on i18n to an app waaaay after active development has stopped, and by and large the textual display portion works flawlessly (this is .net 3.5, with a mix of WinForms and WPF). The problem comes when we let the user set display formats for dateTimes and monetary amounts. The preferences control that lets the user set these allows for the user to set the terms in their language. For example, YYYYMMdd becomes AAAAMMdd for Spanish locales.
The problem is our DateTimeHelper class, which converts between these different formats, saves the user-generated formates, and assorted other helper functions, persists the locale-specific version of these strings instead of translating to a locale-independent format before doing the translation.
Similar situation with monetary amounts, in that decimal and comma positions are variant based on locale.
In both cases I was able to fix the problem by splitting up the functionality in the helper classes in separate 'data-facing' and 'user-facing' method chains, where there is one entry point from user-facing to data-facing that always is visited before any data transmutation occurs.
Hooray for not planning on i18n in the first place!
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
Which is why "data-facing" side I always work in UTC, and I only ever convert to anything resembling local time to show the user.
If this were a hockey game I'd be throwing off my gloves right now bowen.
He's right, the JVM, even a really good one like Dalvik, is a huge waste of battery life, because it has to do the entire JIT step just to run code. Oh, I know, Android has a Dalvik cache where it stores pre-jitted app images, but still.
I stick with sony and toshiba. Pretty much all the big name brands are good. Just replaced an old CRT TV that was probably 15 years old that was Zenith with a sony one.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
I wanted to get into Obj-C for iOS development, but I get the feeling there's a huge hump. Is it even possible to do it on Windows? And I also don't have an iPhone. At least with Android programming I could just run it using an emulator on my Windows box (I'm assuming it's possible to emulate using a Mac).
I wanted to get into Obj-C for iOS development, but I get the feeling there's a huge hump. Is it even possible to do it on Windows?
No.
And I also don't have an iPhone. At least with Android programming I could just run it using an emulator on my Windows box (I'm assuming it's possible to emulate using a Mac).
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited February 2012
You can setup a Hackintosh VM if you want to try out XCode and iOS development, that's what I did. It's probably a bit laggy for real coding (OSX doesn't run real well in a VM), but it works.
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited February 2012
I'd much rather use XML, which while verbose has a super easy to follow structure, and isn't trying to re-invent wheels and make shit different 'just 'cause', than I would use Objective-Smalltalk-enstein.
Sir, we just bolted Smalltalk on to C....what have we done?!
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited February 2012
So I'm thinking of strategies for handling generic container types in my script wrapper system, without the need for the developer to do a RegisterType for every possibly collection they may use. So far I've come up with the concept of RegisterAutoGeneric. For all the registered auto-generics, at proxy generation time, if I encounter a parameter or return value that is assignable from one of my auto-generics, I will wrap that type on the fly.
So for instance, if the end user does RegisterAutoGeneric<IList<>>();, any parameter or return value I find that is based on IList, and who's generic parameter is something I can map (either because it's a core type like string or int, or because it's a mapped complex type), I will auto-wrap that generic in a handy dandy type wrapper.
I would encourage end users to auto-generic interfaces when possible, because a single IList<TType> wrapper can encompass every possible implementation of IList<TTYpe> out there...ObjservableCollection, ReadOnlyCollection, regular old List...etc.
Posts
Remember that's allowing for a maximum of 512, not starting the VM at 512.
-Xms512m would set it at startup.
And if you do threading -Xss512m would allocte 512 a thread.
We're bolting on i18n to an app waaaay after active development has stopped, and by and large the textual display portion works flawlessly (this is .net 3.5, with a mix of WinForms and WPF). The problem comes when we let the user set display formats for dateTimes and monetary amounts. The preferences control that lets the user set these allows for the user to set the terms in their language. For example, YYYYMMdd becomes AAAAMMdd for Spanish locales.
The problem is our DateTimeHelper class, which converts between these different formats, saves the user-generated formates, and assorted other helper functions, persists the locale-specific version of these strings instead of translating to a locale-independent format before doing the translation.
Similar situation with monetary amounts, in that decimal and comma positions are variant based on locale.
In both cases I was able to fix the problem by splitting up the functionality in the helper classes in separate 'data-facing' and 'user-facing' method chains, where there is one entry point from user-facing to data-facing that always is visited before any data transmutation occurs.
Hooray for not planning on i18n in the first place!
I'm just glad we're not handling Right-To-Left support, because the designers here would flip tables if they had to account for that as well.
I am wondering if I should blog about company and project stuff and what of it. I can't go into a lot of details for a while cause yeah.
(Need a master of C#-fu on staff?)
We have an iPhone/iPad game in development.
Way to waste battery life.
MonoTouch? C#-master? Huh? HUH?! You see where I'm going with this?!
(Seriously though, good luck...it's something I've seriously, seriously considered lately)
He's right, the JVM, even a really good one like Dalvik, is a huge waste of battery life, because it has to do the entire JIT step just to run code. Oh, I know, Android has a Dalvik cache where it stores pre-jitted app images, but still.
I think my g/f's phone lasts about a day of normal use. I can go about 2.
My stupidphone can go roughly a week. :P
Samsung. Everything I own electronic is Samsung if I can help it..
I stick with sony and toshiba. Pretty much all the big name brands are good. Just replaced an old CRT TV that was probably 15 years old that was Zenith with a sony one.
Objective-C is the sheriff of alien town.
No.
Yes it is.
My major beef still.
What part? You didn't highlight anything.
Sir, we just bolted Smalltalk on to C....what have we done?!
It's alive...IT'S ALLLIIVVVEEEEE.
You are a teller of lies.
It's all that Java. It's gone to his head.
It's true. Too much Java and I get slap happy.
So for instance, if the end user does RegisterAutoGeneric<IList<>>();, any parameter or return value I find that is based on IList, and who's generic parameter is something I can map (either because it's a core type like string or int, or because it's a mapped complex type), I will auto-wrap that generic in a handy dandy type wrapper.
I would encourage end users to auto-generic interfaces when possible, because a single IList<TType> wrapper can encompass every possible implementation of IList<TTYpe> out there...ObjservableCollection, ReadOnlyCollection, regular old List...etc.