On Thursday, 17 October 2013 at 13:54:34 UTC, PauloPinto wrote:
> No debugger there to talk to the corresponding native browser widgets. :( :(

Hm, some mobile browsers (e.g. Chrome on Android) come with pretty tight remote debugging integration, maybe something like that is available for embedded widgets as well?

David

On 2013-10-17 15:54, PauloPinto wrote:

> Unless you are developing a f**** hybrid application targeting to mobiles.
>
> No debugger there to talk to the corresponding native browser widgets.
> :( :(

You missed my other post about Firebug Lite:

http://forum.dlang.org/thread/l3keqg$e31$1@digitalmars.com?page=4#post-l3moi7:24ak5:241:40digitalmars.com

-- 
/Jacob Carlborg

Am 17.10.2013 17:03, schrieb Jacob Carlborg:
> On 2013-10-17 15:54, PauloPinto wrote:
>
>> Unless you are developing a f**** hybrid application targeting to
>> mobiles.
>>
>> No debugger there to talk to the corresponding native browser widgets.
>> :( :(
>
> You missed my other post about Firebug Lite:
>
> http://forum.dlang.org/thread/l3keqg$e31$1@digitalmars.com?page=4#post-l3moi7:24ak5:241:40digitalmars.com
>
>

Not when you have a custom built Java/Objective-C framework that controls how the requests are handled, with a few hooks for special behaviours.

The wonderful world of enterprise NIH frameworks. :(

--
Paulo

Am 17.10.2013 16:26, schrieb David Nadlinger:
> On Thursday, 17 October 2013 at 13:54:34 UTC, PauloPinto wrote:
>> No debugger there to talk to the corresponding native browser widgets.
>> :( :(
>
> Hm, some mobile browsers (e.g. Chrome on Android) come with pretty tight
> remote debugging integration, maybe something like that is available for
> embedded widgets as well?
>
> David

This is a custom enterprise framework. :(

--
Paulo

On Thu, 17 Oct 2013 15:26:41 +0200
"Chris" <wendlec@tcd.ie> wrote:

> +1
> 
> What can I say? For the web I have to use JavaScript, PHP and Python. Imagine the amount of stupid-yet-hard-to-find bugs I've had to deal with. Bugs that you only become aware of at runtime.
> 

I've gotten to the point where I just refuse to deal with PHP anymore (And I've never been willing to jump on the AJAX-y train).

I believe as much as anyone in "whatever pays the bills", but even then there's reasonable limits where you just have to draw the line for your own sake.

> Am much happier with D (or Java, Objective-C). As for the arguments concerning compile time, extra typing for typing, c'mon, they must be kidding.
> 

Exactly. I often get the impression the static-haters have only ever heard of C++ and Java 2.

> Not to mention increased execution speed, not only in terms of script vs. binary, but also in terms of known type vs. dynamically assigned type.
> 

And in terms of "cache-friendly vs ultra-cache-annihilator-3000".

And in terms of "Simple efficient array of primitives vs Let's replace every trivial primitive of data in the entire program with a big ol' hashtable-of-hashtables, and potentially scatter them all over memory, all just in case some knucklehead decides he just NEEDS to go adding members and methods to some *individual* instance of a freaking integer."

No wonder my Apple II had more responsive text entry than most modern web sites. Hell, I've used typewriters that were faster than some web forms. No joke.

On Wed, 16 Oct 2013 23:00:04 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:

> On Wed, Oct 16, 2013 at 11:07:20PM -0400, Jonathan M Davis wrote:
> > In contrast, with a dynamically typed language, the type of a variable can actually change while your program is running, resulting in function calls being wrong due to the fact that they don't work with the new type. If you're dealing with static typing, the type of every variable is fixed, and the legality of code doesn't suddenly change at runtime.
> 
> 	bool func(Variant x, Variant y) {
> 		return x < y;
> 	}
> 
> 	func(1, 2);	// ok
> 	func(1.0, 2.0);	// ok
> 	func("a", 1);	// hmmm... ;-)
> 

from bottle import route, run, response

@route('/foo')
def index():
	response.content_type = response
	return 'Take that, HTTP!!'

run(host='localhost', port=8181)

On Friday, 18 October 2013 at 02:08:59 UTC, Nick Sabalausky wrote:
> On Wed, 16 Oct 2013 23:00:04 -0700
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
>
>> On Wed, Oct 16, 2013 at 11:07:20PM -0400, Jonathan M Davis wrote:
>> > In contrast, with a dynamically typed language, the type of a
>> > variable can actually change while your program is running,
>> > resulting in function calls being wrong due to the fact that they
>> > don't work with the new type. If you're dealing with static typing,
>> > the type of every variable is fixed, and the legality of code
>> > doesn't suddenly change at runtime.
>> 
>> 	bool func(Variant x, Variant y) {
>> 		return x < y;
>> 	}
>> 
>> 	func(1, 2);	// ok
>> 	func(1.0, 2.0);	// ok
>> 	func("a", 1);	// hmmm... ;-)
>> 
>
> from bottle import route, run, response
>
> @route('/foo')
> def index():
> 	response.content_type = response
> 	return 'Take that, HTTP!!'
>
> run(host='localhost', port=8181)

from bottleneck import runslow

On Friday, 18 October 2013 at 10:23:34 UTC, Chris wrote:
> On Friday, 18 October 2013 at 02:08:59 UTC, Nick Sabalausky wrote:
>> On Wed, 16 Oct 2013 23:00:04 -0700
>> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
>>
>>> On Wed, Oct 16, 2013 at 11:07:20PM -0400, Jonathan M Davis wrote:
>>> > In contrast, with a dynamically typed language, the type of a
>>> > variable can actually change while your program is running,
>>> > resulting in function calls being wrong due to the fact that they
>>> > don't work with the new type. If you're dealing with static typing,
>>> > the type of every variable is fixed, and the legality of code
>>> > doesn't suddenly change at runtime.
>>> 
>>> 	bool func(Variant x, Variant y) {
>>> 		return x < y;
>>> 	}
>>> 
>>> 	func(1, 2);	// ok
>>> 	func(1.0, 2.0);	// ok
>>> 	func("a", 1);	// hmmm... ;-)
>>> 
>>
>> from bottle import route, run, response
>>
>> @route('/foo')
>> def index():
>> 	response.content_type = response
>> 	return 'Take that, HTTP!!'
>>
>> run(host='localhost', port=8181)
>
> from bottleneck import runslow

I like bottlenecks in Blues, not in programs.

On Fri, 18 Oct 2013 12:44:59 +0200
"Chris" <wendlec@tcd.ie> wrote:

> On Friday, 18 October 2013 at 10:23:34 UTC, Chris wrote:
> >
> > from bottleneck import runslow
> 
> I like bottlenecks in Blues, not in programs.

Heh. They're very satisfying to play. Such a rich bass. Also fun to annoy people with :)

On Friday, 18 October 2013 at 12:22:16 UTC, Nick Sabalausky wrote:
> On Fri, 18 Oct 2013 12:44:59 +0200
> "Chris" <wendlec@tcd.ie> wrote:
>
>> On Friday, 18 October 2013 at 10:23:34 UTC, Chris wrote:
>> >
>> > from bottleneck import runslow
>> 
>> I like bottlenecks in Blues, not in programs.
>
> Heh. They're very satisfying to play. Such a rich bass. Also fun to
> annoy people with :)

Yeah, you can do some weird stuff with bottlenecks alright. Maybe
we should have a module in phobos that helps detecting
bottlenecks.

std.bottleneck

struct Slide {
   int frets = 22;
   int strings = 6;
   string E;
   string A;
   string D;
   string G;
   string B;
   string e;
}

struct Amp {
   int volume = 11;
}

struct Neighbor {
   int annoyed = 911;
}