The strongest ideas from the group work suggest that we should separate the project into three major kinds of information:

1. The physical gallery wall and layout-generation rules
2. The scoring model and evaluation rules
3. The artwork catalog and curator annotations

This leads to a clean three-file structure:

• gallery.yaml
• scoring.yaml
• show.yaml

This is a much better approach than putting everything into one file, because each file has a clear purpose.

gallery.yaml should describe the physical wall, the usable space, and the rules for placing artworks.
scoring.yaml should define what the curator values, including both hard constraints and weighted preferences.
show.yaml should define the artworks themselves, including both factual fields and curator-supplied descriptive tags.

A key improvement over the earlier version is that the evaluator should be driven by data rather than hard-coded assumptions. Instead of scattering “magic numbers” throughout the code, we can place the scoring logic into structured YAML records. That makes it much easier to revise the evaluator as the project evolves.

Suggested Overall File Structure

1. gallery.yaml

Purpose:
This file describes the physical display environment and the rules the generator must follow.

It should include:

• gallery and wall identification
• wall dimensions
• coordinate system
• spacing rules
• whether overlap is allowed
• whether vertical offsets are allowed
• whether locked artworks must stay fixed
• output options such as how many candidate layouts to generate

2. scoring.yaml

Purpose:
This file describes the scoring philosophy of the curator.

It should include:

• hard constraints that must be satisfied
• weighted criteria that are scored
• preferred target values
• tolerances
• importance weights
• pairwise lookup tables such as theme similarity
• final score aggregation rules

3. show.yaml

Purpose:
This file describes the artworks being considered for the wall.

It should include:

• identification fields
• artist
• title
• year
• period
• dimensions
• image/source references
• theme tags
• visual intensity
• focal importance
• whether the piece is eligible, required, or locked

A Recommended Design Decision

One especially important improvement is to move from a single theme field to a list of theme tags.

Instead of this:

theme: “portrait”

we should allow this:

theme_tags: [“portrait”, “figure”, “child_portrait”]

This is better because many artworks naturally fit more than one category. A single label is often too restrictive and makes thematic scoring brittle and overly subjective.

Another important design choice is that every scoring criterion should have the same internal structure. For each criterion, we should define:

• label
• what it evaluates
• metric type
• preferred value
• tolerance
• importance
• algorithm method
• data dependencies

That makes the evaluator more systematic and much easier to extend.

Detailed Proposed YAML Structures

Proposed structure for gallery.yaml

schema_version: string
gallery:
  id: string
  name: string
  description: string
  coordinate_system:
    x_origin: "left_edge"
    y_origin: "floor_line"
    units: "ft"
  walls:
    - id: string
      room: string
      label: string
      width_ft: float
      height_ft: float
      usable_x_min_ft: float
      usable_x_max_ft: float
      usable_y_min_ft: float
      usable_y_max_ft: float
      centerline_ft: float
      light_level: float
      viewing_distance_ft: float
      notes: stringgenerator:
  active_wall_id: string
  artwork_count:
    min: integer
    max: integer
  spacing:
    ideal_gap_ft: float
    min_gap_ft: float
    max_gap_ft: float
  placement_rules:
    no_overlap: boolean
    stay_within_wall: boolean
    enforce_order_left_to_right: boolean
    allow_stacking: boolean
    allow_vertical_offset: boolean
    snap_to_grid_ft: float
  lock_rules:
    respect_locked_positions: boolean
    respect_required_artworks: boolean
  output:
    candidate_layouts: integer
    keep_top_n: integer
    export_html: boolean
    export_csv: boolean
    show_score_breakdown: boolean

Proposed structure for scoring.yaml

schema_version: string
scoring:
  profile_id: string
  name: string
  description: string  normalization:
    raw_metric_scale: "0_to_100"
    final_score_scale: "0_to_1"  hard_constraints:
    constraint_name:
      enabled: boolean
      value: float
      penalty_mode: "reject"
      penalty_value: float  criteria:
    criterion_id:
      label: string
      evaluates: "selection"
      metric_type: "target"
      raw_value_range: [0, 100]
      preferred_value: float
      tolerance: float
      importance: float
      scoring_curve:
        in_tolerance_floor: float
        out_of_tolerance_decay: float
        min_score: float
      algorithm:
        method: string
        params: {}
      data_dependencies: [string]
      notes: string  pairwise_tables:
    theme_similarity:
      default_similarity: float
      pairs:
        "portrait|figure_study": float
        "landscape|cityscape": float  aggregation:
    method: "weighted_average"
    use_only_nonfailed_criteria: false
    include_bonus_terms: true
    include_penalty_terms: true  adaptive_feedback:
    enabled: boolean
    allow_weight_updates: boolean
    allow_threshold_updates: boolean
    learning_rate: float
    max_weight_change_per_round: float

Proposed structure for show.yaml

schema_version: string
show:
  id: string
  title: string
  subtitle: string
  curator: string
  source_museum: string
  wall_id: string
  notes: string  controlled_vocabularies:
    theme_tags: [string]
    periods: [string]
    media: [string]  artworks:
    - id: string
      title: string
      artist: string
      year: integer
      period: string
      medium: string
      width_ft: float
      height_ft: float
      orientation: string
      image_url: string
      source_url: string      primary_theme: string
      theme_tags: [string]
      visual_intensity: float
      focal_weight: float
      palette_tags: [string]
      mood_tags: [string]      eligible: boolean
      required: boolean
      locked: boolean
      locked_position:
        x_ft: float|null
        y_ft: float|null      notes: string

Example File 1: gallery.yaml

# gallery.yaml
# Physical setup and generator rules for one gallery wall.schema_version: "2.0"gallery:
  id: "vienna_main_gallery"
  name: "Vienna Art Wall"
  description: "Primary teaching wall used for layout experiments in the gallery visualizer."  coordinate_system:
    x_origin: "left_edge"
    y_origin: "floor_line"
    units: "ft"  walls:
    - id: "W1"
      room: "Main Gallery"
      label: "North Wall"
      width_ft: 10.0
      height_ft: 4.5
      usable_x_min_ft: 0.0
      usable_x_max_ft: 10.0
      usable_y_min_ft: 0.0
      usable_y_max_ft: 4.5
      centerline_ft: 5.0
      light_level: 0.60
      viewing_distance_ft: 8.0
      notes: "Even front lighting; standard viewer approach is centered."generator:
  active_wall_id: "W1"  artwork_count:
    min: 4
    max: 10  spacing:
    ideal_gap_ft: 0.55
    min_gap_ft: 0.30
    max_gap_ft: 0.95  placement_rules:
    no_overlap: true
    stay_within_wall: true
    enforce_order_left_to_right: true
    allow_stacking: false
    allow_vertical_offset: false
    snap_to_grid_ft: 0.01  lock_rules:
    respect_locked_positions: true
    respect_required_artworks: true  output:
    candidate_layouts: 5000
    keep_top_n: 50
    export_html: true
    export_csv: true
    show_score_breakdown: true

Example File 2: scoring.yaml

# scoring.yaml
# Curatorial scoring model.schema_version: "2.0"scoring:
  profile_id: "vienna_balanced_curatorial_v1"
  name: "Balanced Curatorial Profile"
  description: "A target-based scoring profile that rewards balanced, coherent, moderately varied walls."  normalization:
    raw_metric_scale: "0_to_100"
    final_score_scale: "0_to_1"  hard_constraints:
    min_artworks:
      enabled: true
      value: 4
      penalty_mode: "reject"
      penalty_value: 1.0    max_artworks:
      enabled: true
      value: 10
      penalty_mode: "reject"
      penalty_value: 1.0    no_overlap:
      enabled: true
      penalty_mode: "reject"
      penalty_value: 1.0    stay_within_wall:
      enabled: true
      penalty_mode: "reject"
      penalty_value: 1.0    min_gap_ft:
      enabled: true
      value: 0.30
      penalty_mode: "reject"
      penalty_value: 1.0    max_gap_ft:
      enabled: true
      value: 0.95
      penalty_mode: "reject"
      penalty_value: 1.0    respect_locked_positions:
      enabled: true
      penalty_mode: "reject"
      penalty_value: 1.0  criteria:    thematic_cohesion:
      label: "Thematic Cohesion"
      evaluates: "arrangement"
      metric_type: "target"
      raw_value_range: [0, 100]
      preferred_value: 65
      tolerance: 20
      importance: 0.80
      scoring_curve:
        in_tolerance_floor: 0.70
        out_of_tolerance_decay: 0.02
        min_score: 0.00
      algorithm:
        method: "adjacent_theme_similarity_average"
        params:
          default_similarity: 0.10
          use_primary_theme_first: true
          allow_theme_tag_fallback: true
      data_dependencies:
        - "artworks.primary_theme"
        - "artworks.theme_tags"
        - "layout.x_ft"
        - "pairwise_tables.theme_similarity"
      notes: "Moderate cohesion is preferred, not total sameness."    artist_variety:
      label: "Artist Variety"
      evaluates: "selection"
      metric_type: "target"
      raw_value_range: [0, 100]
      preferred_value: 75
      tolerance: 15
      importance: 0.60
      scoring_curve:
        in_tolerance_floor: 0.70
        out_of_tolerance_decay: 0.02
        min_score: 0.00
      algorithm:
        method: "distinct_artist_ratio"
        params:
          adjacency_penalty_same_artist: 5
      data_dependencies:
        - "artworks.artist"
        - "layout.x_ft"
      notes: "Rewards variety without requiring maximum diversity."    spacing_regularity:
      label: "Spacing Regularity"
      evaluates: "arrangement"
      metric_type: "target"
      raw_value_range: [0, 100]
      preferred_value: 70
      tolerance: 12
      importance: 0.70
      scoring_curve:
        in_tolerance_floor: 0.70
        out_of_tolerance_decay: 0.025
        min_score: 0.00
      algorithm:
        method: "gap_variance_vs_ideal"
        params:
          ideal_gap_ft: 0.55
          min_gap_ft: 0.30
          max_gap_ft: 0.95
          out_of_range_gap_penalty: 25
      data_dependencies:
        - "layout.x_ft"
        - "artworks.width_ft"
        - "gallery.generator.spacing"
      notes: "Regular but not rigid spacing is preferred."    visual_balance:
      label: "Visual Balance"
      evaluates: "both"
      metric_type: "target"
      raw_value_range: [0, 100]
      preferred_value: 80
      tolerance: 15
      importance: 0.70
      scoring_curve:
        in_tolerance_floor: 0.70
        out_of_tolerance_decay: 0.02
        min_score: 0.00
      algorithm:
        method: "left_right_visual_mass_balance"
        params:
          mass_formula: "area_times_intensity"
          intensity_floor: 0.50
      data_dependencies:
        - "layout.x_ft"
        - "artworks.width_ft"
        - "artworks.height_ft"
        - "artworks.visual_intensity"
        - "gallery.wall.centerline_ft"
      notes: "Uses visual mass rather than physical width alone."    wall_utilization:
      label: "Wall Utilization"
      evaluates: "both"
      metric_type: "target"
      raw_value_range: [0, 100]
      preferred_value: 75
      tolerance: 15
      importance: 0.70
      scoring_curve:
        in_tolerance_floor: 0.70
        out_of_tolerance_decay: 0.02
        min_score: 0.00
      algorithm:
        method: "occupied_width_ratio"
        params:
          count_internal_gaps: true
          count_outer_margins: false
      data_dependencies:
        - "artworks.width_ft"
        - "layout.x_ft"
        - "gallery.wall.width_ft"
      notes: "The wall should feel used, but not crowded."    period_adjacency:
      label: "Period Adjacency"
      evaluates: "arrangement"
      metric_type: "target"
      raw_value_range: [0, 100]
      preferred_value: 55
      tolerance: 25
      importance: 0.50
      scoring_curve:
        in_tolerance_floor: 0.70
        out_of_tolerance_decay: 0.02
        min_score: 0.00
      algorithm:
        method: "adjacent_period_similarity_average"
        params:
          year_bins:
            - { max_diff: 15, score: 1.00 }
            - { max_diff: 40, score: 0.80 }
            - { max_diff: 80, score: 0.55 }
            - { max_diff: 150, score: 0.25 }
            - { max_diff: 10000, score: 0.05 }
          same_period_bonus: 0.10
          max_pair_score: 1.00
      data_dependencies:
        - "artworks.year"
        - "artworks.period"
        - "layout.x_ft"
      notes: "Moderate historical flow is preferred."  pairwise_tables:
    theme_similarity:
      default_similarity: 0.10
      pairs:
        "portrait|self_portrait": 0.95
        "portrait|child_portrait": 0.92
        "portrait|figure": 0.80
        "portrait|figure_study": 0.90
        "figure|abstract_figure": 0.55
        "landscape|cityscape": 0.70
        "landscape|nature_study": 0.78
        "animal|nature_study": 0.60
        "religious_study|figure_study": 0.58
        "fantasy|abstract_figure": 0.50
        "portrait|landscape": 0.20
        "animal|portrait": 0.18
        "cityscape|religious_study": 0.12  aggregation:
    method: "weighted_average"
    use_only_nonfailed_criteria: false
    include_bonus_terms: false
    include_penalty_terms: true  adaptive_feedback:
    enabled: false
    allow_weight_updates: true
    allow_threshold_updates: false
    learning_rate: 0.15
    max_weight_change_per_round: 0.10

Example File 3: show.yaml

# show.yaml
# Artwork catalog and evaluator-ready annotations.schema_version: "2.0"show:
  id: "vienna_exhibition_01"
  title: "Vienna Exhibition"
  subtitle: "Mixed historical and modern works for wall-layout experiments"
  curator: "Applied Algorithms class"
  source_museum: "Albertina and related reference works"
  wall_id: "W1"
  notes: "Initial teaching dataset for evaluator experiments."  controlled_vocabularies:
    theme_tags:
      - "animal"
      - "nature_study"
      - "religious_study"
      - "figure_study"
      - "figure"
      - "portrait"
      - "self_portrait"
      - "child_portrait"
      - "landscape"
      - "cityscape"
      - "fantasy"
      - "abstract_figure"    periods:
      - "Northern Renaissance"
      - "High Renaissance"
      - "Impressionism"
      - "Neo-Impressionism"
      - "Post-Impressionism"
      - "Symbolism"
      - "Expressionism"
      - "Modernism"
      - "Avant-Garde"    media:
      - "drawing"
      - "painting"
      - "watercolor"
      - "mixed_media"  artworks:    - id: "A1"
      title: "Hare"
      artist: "Albrecht Dürer"
      year: 1502
      period: "Northern Renaissance"
      medium: "watercolor"
      width_ft: 1.7
      height_ft: 2.1
      orientation: "portrait"
      image_url: "https://commons.wikimedia.org/wiki/Special:FilePath/Albrecht_D%C3%BCrer_-_Hare%2C_1502_-_Google_Art_Project.jpg"
      source_url: "https://www.albertina.at/en/press/general-information/masterworks-of-the-albertina/"
      primary_theme: "animal"
      theme_tags: ["animal", "nature_study"]
      visual_intensity: 0.40
      focal_weight: 0.35
      palette_tags: ["earth", "brown", "natural"]
      mood_tags: ["observational", "quiet", "precise"]
      eligible: true
      required: false
      locked: false
      locked_position:
        x_ft: null
        y_ft: null
      notes: "Can also be treated as a nature study."    - id: "A2"
      title: "The Great Piece of Turf"
      artist: "Albrecht Dürer"
      year: 1503
      period: "Northern Renaissance"
      medium: "watercolor"
      width_ft: 1.4
      height_ft: 1.8
      orientation: "portrait"
      image_url: "https://upload.wikimedia.org/wikipedia/commons/f/f6/Albrecht_D%C3%BCrer_-_The_Large_Piece_of_Turf%2C_1503_-_Google_Art_Project.jpg"
      source_url: "https://www.albertina.at/en/press/general-information/masterworks-of-the-albertina/"
      primary_theme: "nature_study"
      theme_tags: ["nature_study", "landscape"]
      visual_intensity: 0.35
      focal_weight: 0.25
      palette_tags: ["green", "earth", "natural"]
      mood_tags: ["observational", "quiet"]
      eligible: true
      required: false
      locked: false
      locked_position:
        x_ft: null
        y_ft: null
      notes: "Bridge piece between natural studies and landscapes."    - id: "A3"
      title: "Praying Hands"
      artist: "Albrecht Dürer"
      year: 1508
      period: "Northern Renaissance"
      medium: "drawing"
      width_ft: 1.2
      height_ft: 1.9
      orientation: "portrait"
      image_url: "https://commons.wikimedia.org/wiki/Special:FilePath/Albrecht_D%C3%BCrer_-_Praying_Hands%2C_1508_-_Google_Art_Project.jpg"
      source_url: "https://www.albertina.at/en/press/general-information/masterworks-of-the-albertina/"
      primary_theme: "religious_study"
      theme_tags: ["religious_study", "figure_study"]
      visual_intensity: 0.45
      focal_weight: 0.30
      palette_tags: ["neutral", "brown"]
      mood_tags: ["devotional", "quiet", "focused"]
      eligible: true
      required: false
      locked: false
      locked_position:
        x_ft: null
        y_ft: null
      notes: "Can pair moderately with figure-study works."    - id: "A4"
      title: "Half-Length Figure of an Apostle"
      artist: "Leonardo da Vinci"
      year: 1493
      period: "High Renaissance"
      medium: "drawing"
      width_ft: 1.6
      height_ft: 2.2
      orientation: "portrait"
      image_url: "https://commons.wikimedia.org/wiki/Special:FilePath/Leonardo_da_Vinci_-_Half-Length_Figure_of_an_Apostle%2C_1493-1495_-_Google_Art_Project.jpg"
      source_url: "https://www.albertina.at/en/press/general-information/masterworks-of-the-albertina/"
      primary_theme: "figure_study"
      theme_tags: ["figure_study", "religious_study"]
      visual_intensity: 0.50
      focal_weight: 0.40
      palette_tags: ["neutral", "brown"]
      mood_tags: ["reflective", "classical"]
      eligible: true
      required: false
      locked: false
      locked_position:
        x_ft: null
        y_ft: null
      notes: "Historical bridge work."    - id: "A5"
      title: "The Water Lily Pond"
      artist: "Claude Monet"
      year: 1917
      period: "Impressionism"
      medium: "painting"
      width_ft: 2.8
      height_ft: 1.6
      orientation: "landscape"
      image_url: ""
      source_url: "https://www.albertina.at/en/press/general-information/masterworks-of-the-albertina/"
      primary_theme: "landscape"
      theme_tags: ["landscape", "nature_study"]
      visual_intensity: 0.55
      focal_weight: 0.55
      palette_tags: ["green", "blue", "light"]
      mood_tags: ["calm", "immersive"]
      eligible: true
      required: false
      locked: false
      locked_position:
        x_ft: null
        y_ft: null
      notes: "Possible horizontal anchor work."    - id: "A6"
      title: "Portrait of a Lady with Cape and Hat"
      artist: "Gustav Klimt"
      year: 1897
      period: "Symbolism"
      medium: "painting"
      width_ft: 1.8
      height_ft: 2.4
      orientation: "portrait"
      image_url: ""
      source_url: "https://www.albertina.at/en/press/general-information/masterworks-of-the-albertina/"
      primary_theme: "portrait"
      theme_tags: ["portrait", "figure"]
      visual_intensity: 0.75
      focal_weight: 0.70
      palette_tags: ["dark", "gold", "ornate"]
      mood_tags: ["formal", "intense"]
      eligible: true
      required: false
      locked: false
      locked_position:
        x_ft: null
        y_ft: null
      notes: "Visually heavy relative to size."    - id: "A7"
      title: "The Sin"
      artist: "Edvard Munch"
      year: 1902
      period: "Expressionism"
      medium: "painting"
      width_ft: 1.5
      height_ft: 2.2
      orientation: "portrait"
      image_url: ""
      source_url: "https://www.albertina.at/en/press/general-information/masterworks-of-the-albertina/"
      primary_theme: "portrait"
      theme_tags: ["portrait", "figure"]
      visual_intensity: 0.82
      focal_weight: 0.68
      palette_tags: ["dark", "red", "green"]
      mood_tags: ["psychological", "dramatic"]
      eligible: true
      required: false
      locked: false
      locked_position:
        x_ft: null
        y_ft: null
      notes: "Heavy visual emphasis piece."    - id: "A8"
      title: "Self-portrait in Orange Cloak"
      artist: "Egon Schiele"
      year: 1913
      period: "Expressionism"
      medium: "painting"
      width_ft: 1.6
      height_ft: 2.3
      orientation: "portrait"
      image_url: ""
      source_url: "https://www.albertina.at/en/press/en-exhibitions/monet-to-picasso/"
      primary_theme: "self_portrait"
      theme_tags: ["self_portrait", "portrait", "figure"]
      visual_intensity: 0.78
      focal_weight: 0.72
      palette_tags: ["orange", "dark", "warm"]
      mood_tags: ["tense", "expressive"]
      eligible: true
      required: false
      locked: false
      locked_position:
        x_ft: null
        y_ft: null
      notes: "Should score strongly in portrait-oriented walls."

Final Recommendation

For the class, I recommend that we standardize on this division of responsibilities:

• gallery.yaml controls wall physics and generation rules
• show.yaml controls artwork facts and artwork annotations
• scoring.yaml controls what counts as a good layout

That separation will make the system much easier to code, test, revise, and compare across groups.

The most important conceptual improvement is this: the evaluator should no longer depend mainly on hard-coded values inside the program. Instead, it should read a structured curatorial model from YAML. That will let us experiment with different scoring philosophies without constantly rewriting the code.

You will work in teams (2–3 students) to improve the gallery layout system.

Part 1: Team Plan (Due March 30)

As a team, submit a document that includes:

• Team members
• Your selected goals (what you want to improve)
• Planned changes or additions
• How you will test and evaluate your ideas

Your plan should be clear and specific enough to guide your work.

Part 2: Final Submission (Due April 6)

Submit the following:

1. Code

• Your modified version of the program

1. Description of Changes

• What you added or changed

1. Results

• Output from your experiments

1. Analysis (1–3 pages)

• What you tried
• What worked and what didn’t
• What you learned

Expectations

• Focus on experimentation and analysis, not just coding
• Use output and results to support your conclusions
• Demonstrate understanding of how algorithmic choices affect outcomes

Goal

The goal is to explore how changes to algorithms and evaluation impact the quality of generated gallery layouts.

Paste this into Overpass Turbo and run it:

[out:csv(::type,::id,name,building,"addr:housenumber","addr:street",::lat,::lon; true; ",")][timeout:90];
{{geocodeArea:Kenyon College}}->.a;
(
  way["building"](area.a);
  relation["building"](area.a);
);
out center;

Notes:

• out center; gives you one lat/lon per building geometry, and ::lat / ::lon work in “out center mode.”
• geocodeArea is an Overpass Turbo convenience macro, not part of raw Overpass QL.

How to export CSV in Turbo:

Export → Data → CSV (or “raw data directly from Overpass API” depending on UI/version).

• Understand pointers to local vs dynamic variables.
• Use nullptr safely.
• Allocate and free memory with new / delete.
• See lifetime pitfalls: dangling pointers and memory leaks.
• Implement and apply a pointer-based swap.

0) Setup (1–2 min)

1. Open the folder containing:
   • pointers_lifecycle_lab.cpp
   • Makefile
2. Build and run once to confirm everything compiles: make run You should see sections titled “Demo” and “Lifetime Pitfall.”

1) Read the Base Output (1–2 min)

In demo_local_pointer() you’ll see a line:

[Base] &x=0x... x=42 px=0x... *px=42

Answer briefly:

• What does &x represent?
• What does px represent?
• Why are &x and px the same?
• What does *px print, and why?

Write your all your answers in the README.md.

2) Explore Dynamic Allocation and nullptr (1–2 min)

Skim outputs from:

• demo_dynamic_allocation() — prints py (address) and *py (value), then deletes and sets py = nullptr.
• demo_nullptr() — shows how to check for nullptr before dereferencing.

Answer briefly:

• Why is it useful to set a pointer to nullptr after delete?
• Why is dereferencing a nullptr invalid?

3) Lifetime Pitfalls (2–3 min)

A. Dangling pointer

• The function bad_return_local() returns &local. That address becomes invalid after the function returns.
• Do not dereference the returned pointer; just observe the printed address and explain briefly:
  • What happened to local after the function ended?
  • Why would dereferencing be unsafe?

B. Memory leak

• The function make_leak() calls new but never delete.
• In code comments, write how you’d fix the leak (add delete and set pointer to nullptr).

Optional (only if your instructor approves): uncomment the two “danger” lines to see what would happen—expect a crash or undefined behavior. Re-comment afterward.

4) Implement pswap (2–3 min)

Open pointers_lifecycle_lab.cpp and find:

void pswap(int* a, int* b) {
    // TODO-1: implement
    // int tmp = *a; *a = *b; *b = tmp;
}

Implement the body so it swaps the values pointed to by a and b.
Then, in main():

• Call pswap(&a, &b) for locals (look for the TODO).
• Rebuild and run: make run
• Confirm the printed output shows a and b swapped.

Checkpoints:

• Before swap (locals): a=10 b=20
• After swap (locals): a=20 b=10

Explain briefly:

• Why do we pass &a and &b here?

5) Implement make_int and Swap Dynamics (3–4 min)

Find and complete:

int* make_int(int value) {
    // TODO-2: allocate with new and return
    // return new int(value);
    return nullptr;
}

Replace the return nullptr; with return new int(value);.

In main():

• Build dynamic ints via make_int(111) and make_int(222) (already present as pa and pb).
• Call pswap(pa, pb) (look for the TODO).
• Run: make run

Checkpoints:

• Before swap (dynamic): *pa=111 *pb=222
• After swap (dynamic): *pa=222 *pb=111

Explain briefly:

• Why do we pass pa and pb (not &pa/&pb) when swapping dynamic values?

6) Clean Up: Avoid Leaks (1 min)

At the end of main():

• Complete the TODO to delete the dynamic integers and set pointers to nullptr: delete pa; pa = nullptr; delete pb; pb = nullptr;
• Rebuild and run. Program should complete normally with no leaks for these allocations.

Optional: Update make_leak() to delete the pointer it allocates.

7) Quick Wrap-Up Questions (1–2 min)

Answer briefly (in comments or on your worksheet):

1. When is it safe to dereference a pointer?
2. Why is returning &local from a function dangerous?
3. What happens if you delete a pointer but forget to set it to nullptr?
4. Define a memory leak. How do you fix one in this program?

Troubleshooting

• Build errors: run make clean then make again.
• Crash/segfault: you likely dereferenced an invalid pointer (dangling or nullptr). Re-comment any danger lines.
• Nothing changes after editing: save the file, run make (not just ./plab), then make run.

Deliverables (what to show your instructor)

• A successful run showing:
  • Base demo line with &x, x, px, *px.
  • Local swap before/after.
  • Dynamic swap before/after.
  • No uncommented danger lines left in final submission.
• Short answers to the reflection questions (comments or worksheet).

Day 1 – Monday, May 12: Vision, Strategy, and Planning

Morning (9:00 – 12:00)

• Welcome & Introductions
• Icebreaker Activity: “Why this project matters to me”
• Project Vision:
  • Overview of ITS for POGIL goals
  • Educational impact, AI potential, and future classroom use
• Strategy Discussion:
  • Phased project plan and development sprints
  • Research deliverables: system + activities + paper

Afternoon (1:00 – 4:30)

• POGIL Foundations Workshop:
  • What is POGIL? How is it different from other pedagogy?
  • Group roles and student collaboration dynamics
• Platform Overview:
  • High-level architecture walkthrough
  • Existing functionality (e.g., doc parsing, role assignment, AI integration)
• Roles & Strengths Discussion:
  • Each participant shares technical/interests background
  • Tentative work areas (backend, frontend, AI, activity design)

Day 2 – Tuesday, May 13: Technical Onboarding and Activity Research

Morning (9:00 – 12:00)

• Development Platform Setup:
  • GitHub access, project cloning
  • Node.js, MariaDB/PostgreSQL, React dev setup
  • Running local dev environment
• Codebase Tour:
  • Backend routes, database schema
  • Frontend architecture and rendering
  • Key functions and pending features

Afternoon (1:00 – 4:30)

• POGIL Activity Research:
  • Review existing COMP 118/119 activities
  • Tag and prioritize POGILs for conversion
• Markup Syntax & Conversion Session:
  • How to translate plain-text POGILs to new syntax
  • Pairwork: convert and preview 1–2 activities
• Design Brainstorm:
  • Whiteboard system gaps, UI ideas, and AI enhancement opportunities

Day 3 – Wednesday, May 14: Planning, Testing, and Roles

Morning (9:00 – 10:40)

• System Specification Workshop:
  • Finalize and document component-level design
  • Group review of API endpoints, schema, UI layout
• Test Plan Discussion:
  • What and how to test: functionality, AI behavior, student flows
  • Begin building a regression test list

Afternoon (1:15 – 4:30)

• Working Group Formation:
  • Assign development leads: e.g., frontend, backend, AI, testing
  • Assign activity leads: tagging, converting, writing new POGILs
• Task Board Setup (e.g., GitHub Projects, Trello):
  • Define initial tasks, due dates, priorities
• Sprint 1 Planning:
  • What gets done by end of May?
  • Setup async check-ins for when Skon is abroad

Day 4 – Thursday, May 15: Workday and Sync

Morning (9:00 – 12:00)

• Hands-On Development Time:
  • Fix deployment issues, connect sheets, parse sample activity
  • Convert/validate 1–2 POGIL activities in the system
• Debugging & Peer Check-ins

Afternoon (1:00 – 4:30)

• Code Jam (small group or pair-based tasks):
  • One pair tackles AI feedback config
  • One pair on activity rendering preview
• Group Sync (3:30 – 4:30):
  • Share progress, blockers, and goals
  • Document takeaways and action items before next week

These platforms offer various features and customization options to suit different development requirements. Depending on your specific needs, such as language support, deployment environment, and extensibility, you can choose the one that best fits your project.

Labdoo is a global non-profit organization that facilitates the donation of refurbished laptops loaded with educational software to schools in need. The platform operates through a network of volunteers who collect, sanitize, and distribute used laptops, ensuring they are equipped with child-friendly educational content in various languages. Schools can register as “Edoovillages” to request devices and participate in the program.

en.wikipedia.org

2. Veyon

Veyon (Virtual Eye On Networks) is a free and open-source software designed for computer monitoring and classroom management. It allows educators to monitor and control computers across multiple platforms, making it easier to manage computer labs. Features include screen broadcasting, remote control, and the ability to lock screens to focus student attention. Veyon supports both Windows and Linux operating systems.

veyon.io

3. Epoptes

Epoptes is an open-source computer lab management and monitoring tool. It enables screen broadcasting and monitoring, remote command execution, message sending, and imposing restrictions like screen locking or sound muting on client computers. Epoptes is suitable for managing computer labs in educational settings.

opensource.com

4. GLPI

GLPI is an open-source IT asset management and service desk system. It assists organizations, including educational institutions, in managing their information systems. Features include inventory management, incident tracking, and administrative and financial management of IT assets. GLPI can help schools keep track of donated computers and manage their IT infrastructure effectively.

en.wikipedia.org

1. log⁡²⁰²¹(n): This function grows very slowly compared to others. It’s a polynomial in log⁡(n)\log(n)log(n), and the base of the logarithm is usually not specified in asymptotic analysis, but it doesn’t affect the growth rate significantly in this context.
2. sqrt(n​): This function grows faster than any logarithmic function but slower than linear or polynomial functions.
3. nlog⁡²(n) : This grows faster than sqrt(n) because it combines linear growth with a logarithmic factor. However, it grows slower than any polynomial function of nnn.
4. n²: This is a polynomial function of nnn and grows faster than nlog⁡²(n).
5. sqrt(2ⁿ)​: This can be simplified to 2^n/2, which grows exponentially but slower than n² and nⁿ
6. n!: This factorial function grows faster than exponential functions like n². Factorials grow faster than any polynomial or exponential function for sufficiently large nnn.
7. nⁿ: This function grows the fastest among the given functions. It’s an exponential function with the base and exponent being nnn, which grows extraordinarily fast.

If you get:

undefined local variable or method `javascript_importmap_tags' for an instance of #

Go to app/views/layouts/application.html.erb and remove the line with:

      <%= javascript_importmap_tags %>

Issue 2: application.css error

If you get the

The asset "application.css" is not present in the asset pipeline.

Do:

yarn add sass
yarn build:css

Issue 3: Delete not working

If delete does not work, you need to add this to app/views/layouts/application.html.erb:

<%= javascript_include_tag "turbo", type: "module" %>

Issue 4: After delete you get a record not found error

The controller current has:

def destroy
    @friend = Friend.find(params[:id])
    @friend.destroy

    redirect_to "/Friends", status: :see_other                                                   
  end

We need to redirect back to the main page. Changer the redirtect_to to:

def destroy
    @friend = Friend.find(params[:id])
    @friend.destroy

    redirect_to root_path, status: :see_other
  end

cat ~/.ssh/id_rsa.pub

Add to server:
ssh-copy-id skon@138.28.162.214 

Login:

ssh username@138.28.162.214 

Start Ruby Project