Live data from Hacker News

Paint16b: A 16 byte paint program written in 12 lines

sizecoding.org

41–50 of 70 posts

Re: Paint16b: A 16 byte paint program written in 12 lines

#41
post #4
post #2

Be helpful if the page mentioned what language the program was written in.

Is assembly not common knowledge anymore?

There is a significant portion of developers ( particular web and app ) and IT staff who never studied computer science in college but instead moved into programming/IT mid career. Most of them probably never heard of or seen assembly code.

However, I would be shocked if anyone who went through a CS program wasn't aware of assembly programming.

Re: Paint16b: A 16 byte paint program written in 12 lines

#42
post #18

Earlier quoted context omitted.

This applies to general public but someone with Freelance Web developer based in Amsterdam. Mostly Node and React. in their bio should probably know what Assembly is...

Why? Serious question. Nothing about that bio says “this person should know about the existence of assembly” to me. And besides, with their question they’ve made an effort to learn about it so I don’t see any reason to criticize them for not knowing. It’s like the xkcd referenced says, every day there are a bunch of people hearing about something for the first time. We should be happy that they hear about it!

We have web pages with multiple seconds of latency because devs don't have a deep understanding of the performance hits of composing programs. And for that you need to understand how the CPU works.

Re: Paint16b: A 16 byte paint program written in 12 lines

#43

Not to poo-poo this (I think this is very impressive) but the reason why it is so small is that it just calls a bunch of bios and mouse driver routines. If those items didn’t already exist the program would surely be larger.

Exactly. Every language has its impressive one-liners and terse programs thanks to the underlying layers of abstraction, even asm.

[deleted]

Re: Paint16b: A 16 byte paint program written in 12 lines

#44

Not to poo-poo this (I think this is very impressive) but the reason why it is so small is that it just calls a bunch of bios and mouse driver routines. If those items didn’t already exist the program would surely be larger.

Exactly. Every language has its impressive one-liners and terse programs thanks to the underlying layers of abstraction, even asm.

"even ASM" - I read that twice to feel good.

Re: Paint16b: A 16 byte paint program written in 12 lines

#45

Earlier quoted context omitted.

Why? Serious question. Nothing about that bio says “this person should know about the existence of assembly” to me. And besides, with their question they’ve made an effort to learn about it so I don’t see any reason to criticize them for not knowing. It’s like the xkcd referenced says, every day there are a bunch of people hearing about something for the first time. We should be happy that they hear about it!

We have web pages with multiple seconds of latency because devs don't have a deep understanding of the performance hits of composing programs. And for that you need to understand how the CPU works.

I do not believe that knowing ASM would even remotely translate into the ability to optimize web pages for latency: understanding high-level concepts like TLS, HTTP/HTTP2, and being to understand JS engines seems far more applicable.

You also seem to be making the assertion that you cannot understand how a CPU works without knowing ASM, which seems equally spurious.

Re: Paint16b: A 16 byte paint program written in 12 lines

#46
SHPaint -- ANSI Art editor programmed in bash, written in 179 lines.[0,1]

  #!/bin/bash
  #
  #  Author: Martin "BruXy" Bruchanov, bruxy at regnet.cz
  #
  
  # Check input first
  if [ ! $# -eq 1 ] || [ "$1" == "-h"] || [ "$1" == "--help" ] ; then
  	printf "Usage:\n"	
  	printf "\t$0 saved_image\n"
  	printf "\n\tImage data will be saved into given filename, if file exist\n"
  	printf "\tit will be displayed and ready to edit!\n"
      printf "\tHit  any time to quit the program.\n"
  	exit 1
  fi
  
  ##################
  # Initialization #
  ##################
  
  IMAGE_FILE=$1
  _STTY=$(stty -g)    # Save current terminal setup
  printf   "\e[2J"    # clear screen, set cursos at beginning
  stty -echo -icanon  # Turn off line buffering
  printf "\e[?9h"     # Enable terminal mouse reading
  printf "\e[?25l"    # Turn of cursor 
  printf "\e]0;-=[ ShPaint ]=-\007"
  
  # Hash array with image data,
  # ... key is "$Y;$X",
  # ... value ANSI colors and brush "b;F;Bm"
  declare -A IMAGE  
  
  # Defaults
  BRUSHES=(       )
  FG=( {30..37} )
  BG=( {40..47} ) # 49 ... default background
  X=0 
  Y=0
  ERASE=0
  BRUSH=${BRUSHES[3]}
  FG_COLOR="1;${FG[7]}"
  BG_COLOR=49
  
  #############
  # Functions #
  #############
  
  function save_image() {
  	printf "\e[2J" > $IMAGE_FILE
  	for i in ${!IMAGE[@]}
  	do
  		printf "\e[${i}f\e[${IMAGE[$i]}\e[0m"
  	done >> $IMAGE_FILE
  	# set cursor under the image
  	printf "\e[$(tput lines);1f" >> $IMAGE_FILE
  }
  
  function at_exit() {
  	printf "\e[?9l"          # Turn off mouse reading
  	printf "\e[?12l\e[?25h"  # Turn on cursor
  	stty "$_STTY"            # reinitialize terminal settings
  	clear
  	echo "Thank for using ansipaint!"
  	if [ ! -z "$IMAGE_FILE" ] ; then 
  		echo "Your image is saved as '$IMAGE_FILE'."
  		save_image
  	fi
  	exit
  }
  
  # X = $1, Y = $2
  function set_pos() {
   	echo -en  "\e[$2;$1f"
  }
  
  function show_pos() {
  	set_pos 65 1
  	printf "x,y = %3d,%3d" $X $Y
  }
  
  function show_brush() {
  	set_pos 70 2 
  	printf "[ \e[${FG_COLOR};${BG_COLOR}m$BRUSH\e[0m ]"
  }
  
  function process_click() {
  #	X=$1 Y=$2
  	# set foreground color
  	if [ $Y -eq 1 ] || [ $Y -eq 2 ] ; then
  		if [ $X -gt 2 ] && [ $X -lt 28 ] ; then
  			FG_COLOR="$[Y-1];${FG[$[(X-4)/3]]}"
  			ERASE=0
  		fi
  	fi
  	
  	# set background color
  	if [ $Y -eq 1 ] && [ $X -gt 34 ] ; then
  		if [ $X -gt 34 ] && [ $X -lt 59 ] ; then
  			BG_COLOR="${BG[$[X-35]/3]}"
  			ERASE=0
  		else
  			BG_COLOR="49"
  			ERASE=0
  		fi
  	fi	
  
  	# set brush
  	if [ $Y -eq 2 ] && [ $X -gt 36 ] && [ $X -le 51 ] ; then
  		BRUSH=${BRUSHES[$[(X-37)/2]]}
  		ERASE=0
  	fi
  
  	# set erase
  	if [ $Y -eq 2 ] && [ $X -ge 54 ] && [ $X -le 62 ] ; then
  		BRUSH=" "
  		BG_COLOR="49"
  		ERASE=1
  	fi
  
  	# DEBUG
  	# set_pos 0 25
  	# printf "$FG_COLOR $BG_COLOR $BRUSH"
  }
  
  function draw_menu() {
  	set_pos 1 1; echo "FG: "
  	for i in ${FG[*]}
  	do
  		set_pos $[(i-30)*3+4] 1
  		echo -en "\e[${i}m\e[0m"	
  		set_pos $[(i-30)*3+4] 2
  		echo -en "\e[1;${i}m\e[0m"	
  	done
  
  	set_pos 30 1; echo "BG: "
  	for i in ${BG[*]}
  	do 
  		set_pos $[(i-40)*3+35] 1
  		echo -en "\e[${i}m   \e[0m"	
  	done
  	echo "   |" # default background (49)
  
  	set_pos 30 2; echo -en "Brush: ${BRUSHES[*]}"
  	printf "  [ Erase ]"
  	show_brush
  }
  
  function load_image() {
  	if [ -f $IMAGE_FILE ] ; then 
  		data=$(sed -e 's/\x1b/E/g;s/E\[0m/\n/g;s/E\[2J//' $IMAGE_FILE | \
  			sed -n -e 's/E\[\(.*\)fE\[\(.*m.\)/IMAGE["\1"]="\2"/ p')
  		eval $data
  		cat 
[0] http://bruxy.regnet.cz/web/linux/EN/ansi-art-sh-paint

[1] https://www.youtube.com/watch?v=aoAMxMukgPY

Re: Paint16b: A 16 byte paint program written in 12 lines

#47

Earlier quoted context omitted.

No, AFAIK MS-DOS always initialises it to zero before starting the program. I'm trying to find a better reference, but I think this[0] effectively explains what state the registers are in on entry to your program. Edit: I take that back. According to [1]: .COM-format executables begin running with the following register values: AL = 00h if first FCB has valid drive letter, FFh if not AH = 00h if second FCB has valid…

The value of BX is however strictly undefined, but practically always 0. Potentially some DOS will load this register with a different value, but probably no version of MS-DOS.

But why not explicitly set the register to 1 rather than assume its 0 and increment it by 1?

Re: Paint16b: A 16 byte paint program written in 12 lines

#48

pretty cool, but why not have it a tiny tiny bit longer code and not strt with 2 flat out assumptions? I mean im not familiar with dos deeply and if these will be true 100% of the time, but as it reads, it reads like silly code which might crash or work unexpectedly in certain situations. either way cool! :D

Apparently these are a valid assumption to make in DOS.

cool :) learning more about low level codes, and everyone tells me never to assume anything about a booting system ,but i suppose DOS will offer a more stable environment for programs to start then 'any x86_^64 hardware' :D thanks for clearing that up! it's a simple program but it sure shows that you can already do a lot with just a few bytes =]

Re: Paint16b: A 16 byte paint program written in 12 lines

#49
post #23
post #15

Earlier quoted context omitted.

I admit my experience is limited, but there are few things that should immediately identify some code as assembly to someone with previous experience, regardless of the platform, such as the prevalence of the "mov" command, a "jump" command or the use of registers, using memory addresses as parameters, accssing stack using "push" and "pop" commands. Registers might have different names depending on the platform, actu…

I suppose my gp wasn't very clear. Language in this context could be just ASM or it could be intel x86 DOS ASM. As I said, the gp could be a master of 6502 ASM, but not be able to tell the difference between ARM and X86.

The question is whether it's recognizable as assembly at all rather than which specific flavor. I think it's correct that all assembly flavors tend to look very similar to each & very dissimilar from any language.

Re: Paint16b: A 16 byte paint program written in 12 lines

#50
post #4
post #2

Be helpful if the page mentioned what language the program was written in.

Is assembly not common knowledge anymore?

lots of 'programmers' don't even know what a debugger or a cpu is xD let's not talk about common knowledge in 2018 please its depressing :D
Post reply on HN