day-03                         kanel.gif.ler
  ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*

  date: 2026-09-03 (Thu)

  agenda:
  - work on TGPL chapter 1 [ ]
  - work on tour of go [x]
  - draw a gopher [x]

  ---

  pizza SLICE
  ============

  yesterday night, i read about go slices (since
  i wanted to know why one can shrink them "from
  the right" without decreasing their capacity,
  as seen in the tour of go,
  but not "from the left"; it makes sense,
  since they kinda work like:

  // ahhh, i C!
  typedef struct pizza {
    T *data; // the zeroth element
    ssize_t len, cap;
  } pizza;

  so s[m:] advances the data pointer by
  m and subtracts m from len (and from cap),
  while s[:n] only has to subtract n from
  len, so the data ptr and cap can stay
  the same.

  goo illustrations in that article:

=> https://go.dev/blog/slices-intro

  also:

  > It’s important to understand that even
  > though a slice contains a pointer, it
  > is itself a value. Under the covers,
  > it is a struct value holding a pointer
  > and a length. It is not a pointer to a
  > struct.

  so, when passing a slice to a function,
  the underlying data array will be
  modified, but not the slice value,
  so we have to return that (or pass
  the slice as a pointer);

  when we e.g. append to said slice in
  the function, the underlying data
  array might exceed capacity and
  be re-allocated, so as a result,
  the old slice will still store
  the old data ptr i think?

=> https://go.dev/blog/slices

  QUESTION:

  if we have
  > var a := int[]{3,1,4,1,5}
  are
  > b := a
  and
  > b := a[:]
  exactly the same? i think so?

  QUESTION 2:

  > a := make([]int, 2048)
  > a = a[len(a) - 1:] // cap == len == 1

  this wastes lots of memory, right?
  as in, the data up until the last
  element, which we still reference
  with the slice, cannot be deallocated
  by go?

  ah yeah:

=> https://go.dev/blog/slices-intro#a-possible-gotcha

  > Since the slice references the original
  > array, as long as the slice is kept
  > around the garbage collector can’t
  > release the array


  const ant ine nople
  ===================

  i also just found out golang has no concept
  of const pointers (e.g. for function
  parameters, which i like using in C),
  i wonder why. in general, const seems to
  work quite different in golang; i like those
  semantics i think:

  > An untyped constant takes the type needed
  > by its context.

=> https://go.dev/tour/basics/16

  ---

  circles
  ========

  the tour of go slice exercise is cool!

=> https://go.dev/tour/moretypes/18

  my output: tour-of-go-exercise.jpg

  annoying imo: unused variables in golang are
  an error :(
  also why Float64 instead of just f64 >:(

  ---

  for loop fix
  =============

  this is interesting:

=> https://go.dev/blog/loopvar-preview

  ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*